[Development] clunky-animations-issue in Qt5 scenegraph

[gunnar.sletta at nokia.com]

On Apr 19, 2012, at 4:54 PM, ext Samuel Rødal wrote:

> On 04/19/2012 04:38 PM, ext André Bergner wrote:
>> 
>>> 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 :)
>> 
>> 
>> Thanks a lot, Gunnar. That already clearified a lot :)
>> Ok, I have a few more detail questions.
>> Firstly, the QML_FIXED_ANIMATION_STEP-trick worked great on Mac, velvet
>> there, now. Is there an API-call to set this inside the program?
> 
> I think this could be fixed without the application needing to call a
> special function.

The function is QUnifiedTimer::setConsistentTiming. It has a side effect though, which is why it is not set by default, and that is that animations are advanced by 16 ms regardless. That means that frames that take longer than 16ms to either prepare or render will slow the animation down. But if you consider it, what we have right now looks way worse, so maybe we should just change the default to use consistent?

To remedy this problem, you would need to reimplement a custom animation driver using the scene graph adaptation API, or if it is a good one, replace the one that is there in the threaded renderloop :)

If you are really curious about the adaptation layer it is pure private API, no guarantees source or binary, but it opens up a few doors. Have a look at QSGContext and QSGContextPlugin in the src/quick/scenegraph directory and you will find it. These is some class docs in there, though it is not a fully documented class by any means.

> 
>> On Windows and the embedded ARM platform (no wayland or X11, rendering
>> directly into backbuffer) the trick did not work.
>> What can I do there? You mentioned that device adaption API plugin
>> thing. Is this documented somewhere? Where should I start looking for it?
>> At least on Windows I'm sure that the driver is set to be blocking on
>> vsync, but animations are still glitching around.
> 
> I guess he's referring to the platform plugin needing to report that it
> supports the BufferQueueingOpenGL capability in QPlatformIntegration.
> 
> --
> Samuel
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development