Running my app on the N900, much to my dismay I noticed a visable lag in the transitions. Disabling OpenGL seems to have sped things up quite dramatically - and it's noticable toggling between the two. In both cases I made it run full screen.

Anyone else had similar experiences? Seems rather counter-intuative...

My experience has been the same. I was also forced to disable OpenGL acceleration due to performance issues. Doing so has resulted in gradients looking quite poor (colour banding), along with one or two other weird behaviours that forced some design compromises.

Test it on Meego handset also and then send bugreports too the Qt teams cause this issues sounds bad imho.

I haven't delved much into Qt yet but I wonder whether the GL for Qt is full OpenGL, not GLES? Therefore, my suggestion is that the speed reduction occurs in changing from full to ES, even if the instructions/features you are using are within the ES spec, because QML includes the full instruction set [1] but the software has to adapt to the operating environment (N900).

Is there anyway you can use C/C++ & OpenGL ES for the graphics and provide a few hooks into the UI? I think there is a QtOpenGL, is there a QtOpenGL ES you could try?

I think that makes sense!!
[1] instruction set: these are only my thoughts, not definitive.

I hope you can find a work around to get smooth, shiny graphics!

Did you run your app in fullscreen ?

As this make a little difference. But don't be fool, qml is slow in real use, as it s consume more memory, and this isn't the best part of the n900.

Curiously opengl rendering is really ugly and slow on my phone. I think it depends on the type of application though. Graphicssystem Raster rendering is much faster and prettier than opengl in Tweed Suit at least.

Edit: Actually, I use Raster for N900 and Windows Desktop, and OpenGL for Linux Desktop

@mece do these pieces of software use the full OpenGL instruction set or the ES versions?
If software using the complete version is somehow compiled down to run on the N900 it would probably look funny (analogous to lossy-compression) - for software to have proper hardware acceleration, it must explicitly use OpenGL ES. Even then I think there some bugs like vsync.

Edit: by 'software' I refer to the one being created, not the library/framework. By analogous, I mean that the embedded library is smaller than the full version so some functionality might be lost.

QML is not inherently slow - but I do agree that at this point it's all too easy to get carried away and write things in ways that do incur a performance overhead. It really helps if you know how the underlying tech 'thinks' (this is not QML specific, writing C code anticipating how the assembly will look like also can give very interesting results). In this case, however, it's about our presumption that everything hardware accelerated must be faster than anything done on the CPU, but reality can get in the way (I think the most famous one in Maemo land is that the N800 does media playback better with *lower* clocked DSP). The OpenGL situation is a similar one - there are many caveats that can (and do) kill OpenGL performance so on the N900 you're often better off relying on the relatively zippy CPU.

The software you're referring to is Qt, since you don't really choose what instruction set to use from the application, Qt takes care of that. So it depends on what device is used. It uses ogles on my N900 and ogl on desktop.
And yeah, vsync doesn't work in maemo5.

QML is most certainly not slow in real use. Turning off OpenGL gave a huge performance boost, and I'd say the GUI performance of my Python / QML app is far greater than the built in C / GTK ones.