We have a huge performance problem when using QPainter's drawRect function in a QGLWidget on Maemo on the Nokia N900. The FPS drops to ~2-3 and the device is completely unusable. The performance hit is quite strange, as it does not appear all the time, but just most of the times I run the application on the device. Other times it runs fine, with an FPS of ~40-50.

The error is directly connected to the QPainter class, as I have a button in my application to activate the QPainter drawing of rectangles (used for menus and windows). Also, if I comment out the drawRect functions, but leave everything else as-is, it runs smoothly. QPainter's drawText function does run smoothly, however.

Running the application in Ubuntu or on Windows does not show a performance hit at all (not even slightly), so this is strictly related to the Maemo device. The device is running the libqt4-maemo5-* libraries.

Do you guys happen to know how I could try to debug this? I'm kind of stuck between wondering if there is something wrong with my mobile or Qt's drawRect-function - or my own code, of course.

If you need to have a look at the source, you can check out the latest tarball for our project (a game) from our git repo:

http://github.com/dragly/loose_cannon/tarball/master

I've posted this over at QtCentre as well, but I didn't get too much response over there, so I'm reposting here.

Are you doing anything that may be scaling a PixMap?

Might be worth checking out http://blog.rburchell.com/2010/04/ev...god-kills.html...

No. I am just drawing primitives. More specifically rectangles and rounded rectangels. I don't think there should be any scaling of any kind similar to pixmap scaling.

We are probably going to look at pixmaps later on though, so thanks for passing on that link! It might come in handy in the future.

Any other ideas about what might cause the low FPS?

Have you tried to run your QT app with

./myApp -graphicssystem opengl

I think this uses the hardware acceleration but last I heard it was still experimental.
Let us know how it performs...

That didn't make any difference. And I think QPainter uses OpenGL already when drawing primitives like rectangles on a QGLWidget? After all, the application runs smooth every once in a while - without any changes...

After reading the link above, I decided to do some profiling and benchmarking. The results where surprising, but didn't really help me understand what the real problem is. Maybe you guys do?

Profiling only showed me some list operations on nodes (used for waypoints) as the most time consuming. This is however unrelated to the main game loop since the nodes are generated and placed out when loading the game, and are only used again when moving things around in the game. So this is obviously not the real time-waster.

However, the profiling missed completely on the total time used to run the application. While I had the game running for 2-3 minutes, the profiling showed that the sum of all CPU time was about 11 seconds.

I did some benchmarking in the main game loop with simple timestamps, and I found something very interesting. The longest time intervals were not around QPainter's drawRect functions, but when I was drawing 3D objects. I removed the drawing of the objects in question, tested again, and suddenly the timewaster was the QPainter::beginNativePainting(). Then I ran the game a few more times without changing anything, and I realized that the timewasting functions changes for each time.

With other words: There isn't something specific in the game loop that slows the application down, it appears to be completely random functions related to QPainter or OpenGL.

I have no idea why this happens, but I'm starting to think that it might be something happening outside the scope of our application which does this. Maybe something in another thread? Could it be the GPU running out of memory and doing some cleanup? (I doubt this myself, since there aren't that many objects being drawn). Could software rendering be kicking in for any reason?

If the reason for a weird behaviour moves around if you change your code, the reason most often IS your own code.

Try to cut away as much as possible to get a minimal example that displays the behaviour. If creating such a minimal example proves difficult, there is even more reason to take a longer look at your own code.

Yes, that would be reasonable to think, but the strange thing is that the weird behaviour moves around even if I don't change anything. The latest benchmarks I did showed that the slowdown in the main loop moved to a lot of different places.

I could try to make a minimal example from this, but that would probably just be the hellogl_es2 example from Qt - which ran fine the last time i tried.

intersting just thought i would let you know i was using qpainter to paint to a qglwidget with no preformance drop or at least not that i relised. must admit tho had no 3d objects just pixmaps drawn using qpainter. r you testing on device?

The following suggests that you changed your code:
And when I say "a minimal example", I'm referring to taking your code and commenting out or removing bits to make sure you still get the problem. To compile some example from another source might be interesting (if you get the same problem) but says nothing about your code.

Yes, sorry about that. I changed my code, but I've run the benchmarking a couple of times after this without changing the code in between each benchmark.
That's true. I will give it a try and post back with the results.