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

[Stephan Kanthak]

Hi Samuel,

Am 15.11.2012 um 13:24 schrieb Samuel Rødal <samuel.rodal at digia.com>:

> On 11/15/2012 11:07 AM, Stephan Kanthak wrote:
>> 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.
> 
> 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.

I didn't had much time to test yesterday, but that was a big step forward. The stuttering is gone and now tearing is a bit more obvious, but it's close to smooth. At least with eglfs. Minimalegl seems to behave differently. The animations there still show some more jumps, but overall they seem to run faster compared to eglfs with that env variable being set.

> You might also want to try the customcontext renderer from 
> ssh://codereview.qt-project.org:29418/playground/scenegraph.git

See my post, I already did :-). Although I still have to try again using the RenderThread stuff + that env variable in my own little QML application.

> After building and doing make install there you should be able to use it 
> by doing "export QMLSCENE_DEVICE=customcontext" or running with 
> --device=customcontext

That's great info. I already wondered how customcontext gets used and I obviously didn't use it yet :-).

> If it's a timing issue you might also try
> QML_FIXED_ANIMATION_STEP=1

I will try all this on Monday next week and report my findings.

Thanks a lot already.

Best,
Stephan