[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Stephan Kanthak
stylon at gmx.de
Thu Nov 15 11:07:15 CET 2012
Hi,
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
http://qt.gitorious.org/qtplayground/scenegraph
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
http://blog.qt.digia.com/blog/author/gunnar/
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,
Stephan
More information about the Interest
mailing list