[Development] clunky-animations-issue in Qt5 scenegraph

[gunnar.sletta at nokia.com]

On Apr 19, 2012, at 2:58 PM, ext André Bergner wrote:

> Hi All,
> 
> I'm currently playing around with simple QML test programs in order to evaluate the smoothness of animated QtQuickItems.
> 
> As mentioned in the blog entry here http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ in Qt4 the drawing update and render calls have not been synced, which led to jerky animations. Apparently this is supposed to be solved in Qt5. Comparing a simple QML-test app (rectangle moving with constant velocity) between Qt4 and Qt5 there are some obvious improvement in the animations quality.
> 
> However, with Qt5 I still perceive some occasional jumps in the animation, more rarely, though, hinting to some timing issue still existing. These jumps can be perceived in several testing environments: Mac, Windows, Linux (x86 as well as embedded ARM). I'm using the current Qt alpha release to run those tests. I'v also compared to other test apps using directx or opengl running the same test perfectly smooth. Apparently these jumps seem to originate in the opengl render call not synced to vsync.
> 
> Is this an issue the Qt-devs are aware of? And if yes, is this going to be solved, or am I'm doing something wrong (some missing switch for instance)?
> In the source file Qt5/qtdeclarative/src/quick/items/qquickwindowmanager.cpp it says "OpenGL pipeline will not block for vsync in swap". Does that mean Qt scenegraphs render calls are not synced to vsync? And if yes: WHY?
> 
> *watinting for enlightment*


There are two implementations currently, the threaded renderer which is used on Wayland and Mac and the "trivial" one running on the GUI thread. In addition to that, the device adaptation API in scene graph allows you to plugin in your own. 

The threaded renderer is used by default on wayland, mac os x, and I believe also eglfs. It expects a blocking rendering pipeline, but doesn't expect swap itself to block. On single-windowed setups, the distinction is not relevant, which is why eglfs can use it. The reason it needs this particular blocking behavior is so that it can share one GL context between all opened windows in that process and swap them in turn and then tick the animations once per "all frames". This is true for Mac OS and wayland, and eglfs gets away with it because it only has one window so it can block wherever it likes, as long as it is once per frame. However... On Mac OS X, there is a small quirk in that it doesn't block in line with vsync, it instead fills up the buffer queue and then blocks. This leads to animation frames being prepared at non-multiples of 16 which comes out as less smooth. The right fix for the problem is to write an animation driver that ticks with increments of 16.66, but as a workaround you can export QML_FIXED_ANIMATION_STEP and you should see velvet.

The GUI threaded, the trivial window manager, is used on X11 and Windows by default. It does not rely on vsync. It just ticks a timer for the animation and calls update, very much like the traditional Qt repaint is doing things. If you have one window and specify in the driver that you should block on vsync this should give you almost smooth behavior, but not quite as the timer some times gets out of sync with the actual vsync. This reminds me that we really should offer a second trivial window manager that runs in the gui thread and that ticks animations once per vsync. It could only be used with a blocking driver when there was only one window on screen, but for that usecase, it would be almost as good as the wayland/mac implementation.

I hope that clarifies the current state a bit :) 

cheers,
Gunnar