Conversation
TopBar::paintUserpic() called update() from inside the paint handler while a video userpic was playing, so every paint scheduled the next one. With swap interval 0 on Linux nothing throttles that loop and the window is flushed as fast as the GPU returns buffers. Repaint from the player's UpdateVideo notification instead, like UserpicButton does. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
|
|
if i read the description right, this fixes #30489? |
|
Yes, looks like it. Same rendering path, just spins either on CPU raster (RHI off), or spins on gpu side with opengl/vulkan rendering. Just tested on cpu; unpatched vs patched dev (7.2.6): 97% -> 9% CPU, ~2100 -> ~70 window commits/s. |
Are you sure? Media on main window still always draws with CPU |
|
Yes, frame itself is always drawn by CPU, I missed a number in the RHI ON comparison. Pre patch:
Post patch:
Render is CPU in both cases, downstream of that RHI ON adds a GPU step per flush: upload the dirty region, redraw the whole window. So GPU load is technically a side effect, I didn't separate the two at first properly as it mostly showed up for me as desktop/compositor lag while the 9950x3d2 host cpu didn't suffer much from one spinning core out of 32 |
3 participants
With the profile column open on a chat that has a video userpic,
TopBar::paintUserpic()re-queues itself viaupdate()on every paint. Since the default surface format uses swap interval 0 on Linux, the loop is unthrottled.Measured on Linux/Wayland (KWin, AMD Raphael iGPU, 3840x1100 window), Flatpak 7.1.3:
Built with the CentOS build image and verified on the same setup.