[Development] clunky-animations-issue in Qt5 scenegraph

[André Bergner]

> 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?

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.

thanks again,
André
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120419/f5eb0d0f/attachment.html>