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