[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour

Stephan Kanthak stylon at gmx.de
Thu Nov 15 11:07:15 CET 2012


some background first: for some little project I'm planning to prototype 
a custom UI. I got interested in Qt5, because of QML + Javascript. The 
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 
Javascript, block the main thread with something else or run processes 
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 
hit the "Block" button. That starts an infinite javascript loop in the 
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 
process does not exceed 25% CPU even when running that Javascript loop, 
but without it uses <10%. I would expect ~0% without (most animations 
just update a single property) and 100% with that Javascript loop. 
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 
from that playground scenegraph. Using RT objects and the Javascript 
main thread blocker loop improves smoothness a little bit, but not 
comparably as smooth as in the scenegraph demo.

If Gunnar is listening to this list: I've no idea what is going on here 
:-). It actually behaves so much against all my predictions (except the 
TI demos) that I'm a bit puzzled. But maybe we can find out why it 
behaves so strange.

Qt5 is not mandatory for my little project, so I could move forward with 
plain EGL/OGLES2, but using QML + Javascript would make things for me a 
lot easier.

Thanks & best,

More information about the Interest mailing list