> 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é
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
