QML window resize/move flicker - qt

Question

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?

Answer 1

You can try this:
int main(int argc, char* argv[]) {
QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);
or
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
The first option uses OpenGl2DirecX angle library (like Google Chrome)
The second one uses OpenGL emulation by software... for small programs work very good and is 100% compatible with old OS like Windows XP.
Note: You can try with Qt 5.7 and new Qtquick.Controls 2.0 ...performs much better...
https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/

Answer 2

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:
Actual resizing of the window is started right after _NET_WM_SYNC_REQUEST is sent by The Window Manager. And not when the app receives it. The window could be even updated at this time, when sync request is sent, but not handled by the app yet. Which will draw the content with outdated geometry.
_NET_WM_FRAME_DRAWN could help to sync between resizing and updates, but also might not be supported (and guess it is not) by The Window Manager.
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

Answer 3

In my case, i solved this by adding the next flag:
QQuickWindow::setSceneGraphBackend(QSGRendererInterface::Software);
But this will add other rendering problems. Or not.

Answer 4

In golang therecipe/qt this help me :
func main() {
var format = gui.NewQSurfaceFormat()
format.SetVersion(4, 5)
format.SetProfile(gui.QSurfaceFormat__CoreProfile)
format.SetRenderableType(gui.QSurfaceFormat__OpenGL)
format.SetSwapInterval(0)
format.SetDefaultFormat(format)
os.Setenv("QT_SCALE_FACTOR", "1")
ap := widgets.NewQApplication(len(os.Args), os.Args)
ap.SetApplicationName("APP 1.1")
System: Linux debian 10
gpu: Radeon 570
but the animations are faster because not all frames are rendered...