[Development] clunky-animations-issue in Qt5 scenegraph

[Samuel Rødal]

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.

> 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