[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
samuel.rodal at digia.com
Thu Nov 15 13:24:26 CET 2012
On 11/15/2012 11:07 AM, Stephan Kanthak wrote:
> some background first: for some little project I'm planning to prototype
> OMAP4 platform I use (a modified Kindle Fire, but very similar to the
> Pandaboard) offers EGL/OGLES2 and I got some drivers running from TI
> directly on LinuxFB without XCB. I couldn't use their latest drivers SDK
> (only OMAP3), but please ask TI that question why they stopped
> delivering a driver SDK for their OMAP4 suddenly about a year ago.
> Qt5 compiles fine now against those drivers (see my previous post) and
> demos/examples run. Since then I also got extension stuff, e.g. from
> to compile and run.
> The EGL/OGLES2 demos from TI run smoothly, despite some little tearing
> here and there. Only OGLES2Water seems to stutter about once a second,
> but let's take that as an exception. The TI driver is also configured
> for 4 buffers (!). There's a little tool provided that tells you how
> many buffers it manages to allocate and depending on how much memory is
> being reserved at boot time, I do see that it allocates also 1, 2, 3
> buffers. From the TI demos I conclude that the driver seems to buffer,
> but don't always swap buffers correctly at VSYNC time. Although with
> some demos (e.g. OGLES2ChameleonMan) it's pretty hard to find any tearing.
> Now here's my problem: with unmodified Qt5 I don't get *any* smooth
> animation. As far as I understood Gunnar's blog posts at
> this should not happen with Qt5/eglfs, except maybe when I use
> in the background. But none of the latter is the case. So, I digged a
> bit deeper. Here's what I tried:
> 1. according to Gunnar's post, Qt5 tries to predict animation states for
> the time a buffer is being displayed. So, I tried to find out what
> refresh rate Qt5 assumes and it's indeed hard-coded to 60Hz and not
> being overloaded by eglfs (see qplatformscreen.cpp, eglfs should be
> corrected to ask the driver for the display's refresh rate in my view).
> The Kindle Fire does some strange pixel-clock initialization and at the
> end seems to fall back to something very close to 50Hz. So, I changed
> that in the code => but, no effect at all.
> 2. I tried the stuff at http://qt.gitorious.org/qtplayground/scenegraph.
> The examples in the animators/test directory I did run with qmlscene. By
> default all of them are stuttering a lot, no matter wether it's the
> RenderThread or MainThread animation. Surprisingly, this changes once I
> main thread. All of a sudden the RenderThread animation is perfectly
> smooth and the MainThread animation becomes sufficiently smooth, but
> just not as perfect as the RenderThread animation. Surprisingly, the
> but without it uses <10%. I would expect ~0% without (most animations
> And... I would have expected the animations to be smooth without the
> block loop and stuttering when it's running.
> 3. I did a tiny prototype qml animation and that runs really perfectly
> smooth using qmlscene on a MacBook Air (that's why we all love macs,
> right :-) ). Running the same on my platform stutters like the stuff
> main thread blocker loop improves smoothness a little bit, but not
> comparably as smooth as in the scenegraph demo.
Are you doing "export QML_FORCE_THREADED_RENDERER=1"? Because afaik
without that you won't get the threaded renderer. Most issues I've seen
with animations have been due to not using the threaded renderer.
You might also want to try the customcontext renderer from
After building and doing make install there you should be able to use it
by doing "export QMLSCENE_DEVICE=customcontext" or running with
If it's a timing issue you might also try
More information about the Interest