I'm developing a simple QML
application right now and I noticed that resizing and moving a QML
window generates an ugly flicker compared to a QtWidgets
window, for instance.
So I created 2 test applications to show the difference:
QWidgets:
QML:
As you can see the QML
version of the application flickers pretty ugly while the QtWidgets
one is clean. Now this gets pretty ugly when your UI grows in complexity.
Do you have any knowledge about this? Is this a bug? Is there any fix/workaround for this issue?
The issue with resizing of QML apps is about updating a window with outdated geometry. The fix would be to sync the updates and resizing.
Since there might be sudden updates from update timer to render scene graph, which can update the window at any time, it causes drawing of the content with outdated geometry. https://bugreports.qt.io/browse/QTBUG-46074
Either Basic or Extended synchronization should be used to synchronize resizing and the window updates. Currently Basic sync is used and implemented in Qt, but still need to synchronize the window updates (from timer) with resizing events from Windows Manager.
But, as always, there is a list of issues:
The problem is observed when the window is being resizing too fast. Since sync events (from WM) should be sent consistently, next after previous:
<= _NET_WM_SYNC_REQUEST is sent from WM, the size is changing now.
_NET_WM_SYNC_REQUEST is received and handled by app.
<= some other events received, like new geometry.
.. update the content, swapBuffers.
=> Sent _NET_WM_SYNC_REQUEST_COUNTER back to WM.
<= _NET_WM_SYNC_REQUEST is sent again from WM, the size is changing.
.. swapBuffers // here is the problem, the update is performed when the window is being changing its geometry.
_NET_WM_SYNC_REQUEST received and handled again.
So the issue happens when (7) swapBuffers appears after _NET_WM_SYNC_REQUEST is sent but not received/processed yet.
And finally conclusion:
In other words, either basic or extended synchronization does not help, (at least without _NET_WM_FRAME_DRAWN), because there is no way to know when actual resizing is done.
Extended sync protocol is a try to handle this, but since actual changing of geometry is done without syncing with the client, as I can see, without _NET_WM_FRAME_DRAWN there is always a chance to update the window with outdated geometry.
https://lists.freedesktop.org/archives/xcb/2019-February/011280.html