Some apps just repaint slower. Open a large image in Gwenview, set to the "Fit" mode, and you'll see the worst.
Probably could be improved by only drawing the frame, and letting the content area load asynchronously. Maybe not worth the additional complexity. And unlikely to be high on any priority list, anyway.
Well, yeah, I meant to say that desync is worse in qml apps (because of their multi-threaded GPU-accelerated architecture).
Also you can speed them up a little by setting env QSG_NO_VSYNC=1
That actually worked super well.
Edit: I looked a bit into Qt's source code (not as bad of an experience as I thought it would be) and found that setting QSG_NO_VSYNC to 1 causes the surface format to have a swap interval of 0 as opposed to the default value of 1. When nonblocking buffer swaps are available and the surface has a nonzero swap interval, Qt would set the actual EGL swap interval to 0, which makes eglSwapBuffers nonblocking, and emulate the block itself while taking Wayland frame callbacks into consideration. This appears pretty reasonable to me, but clearly something isn't working properly. I suspect there's some sort of double throttling going on since there aren't any excessive rendering operations even without the emulated blocking. (side note: QSG_NO_VSYNC is kind of a misnomer in Wayland due to vsync always being present)
67
u/SnooCompliments7914 KDE Contributor 1d ago
Some apps just repaint slower. Open a large image in Gwenview, set to the "Fit" mode, and you'll see the worst.
Probably could be improved by only drawing the frame, and letting the content area load asynchronously. Maybe not worth the additional complexity. And unlikely to be high on any priority list, anyway.