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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest