The animation logic in the threaded renderer assumes that you block at some point, but not necessarily not in swapBuffers(). That is what "BufferQueuingOpenGL" means. If you are not blocking anywhere, then you will render at max CPU and rendering many more buffers than the screen can display.
Typically, the wayland client app should post buffers as fast as it can and block on re-aquiring frames it previously sent to the wayland server as the wayland server releases them. The wayland server should be blocking either in swapBuffers or in some other part of the pipeline so it gets throttled at 60FPS (or whatever the screen refresh rate is). That will cause the compositor to release frames back to the client at roughly 16ms intervals. Because this is all asynchronous and release times can vary with several milliseconds, you want to use constant timing IF you manage to always hit 60FPS, as that will give the most velvet user experience. If you are not able to consistently hit 60FPS, you should use a timer based animation driver. (ref: http://blog.qt.digia.com/blog/2012/08/01/scene-graph-adaptation-layer/) I believe the blocking on reaquire is already in the wayland client, so you only need to find a way to block the buffer posting to the display in the server. eglSwapInterval(1) in the eglfs plugin, perhaps? cheers, Gunnar On Mar 20, 2013, at 11:57 AM, Thomas Senyk <[email protected]> wrote: > Hi, > > when using qtwayland as client && server, then currently the animation speed > is way too high (~6x what it should be on my machine) > (got reported by at least one other person in #qt-lighthouse) > > I've dug a little bit and found that: > BufferQueueingOpenGL (QPlatformIntegration::Capability) > is enabled for wayland, which triggers: > QUnifiedTimer::instance(true)->setConsistentTiming(true); > (see QQuickWindowManager::instance()) > > Which results in a fixed(!) 'delta' (animation progress 'time') of, in my > case > 16, BUT the 'proceed'** isn't done every 16ms, but rather every ~1ms. > > If using weston the 'proceed'** is called every ~10-12ms, which is still > wrong, but way closer then ~1ms ... that's why weston looks ok but > qtcompositor looks broken. > > **QUnifiedTimer::updateAnimationTimers > > > > I'm not sure where to problem originates from and how to fix it ... > My current guess is: > bool QQuickRenderThreadSingleContextWindowManager::event(QEvent *e) > with (e->type() == QEvent_Sync) is called way to often. > > It should be called every 16ms (as close as possible) ... shouldn't it? > > > Can any elaborate what's the use-case for consistent-timing and how it's > supposed to work? > > Greets > Thomas > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
