After two and a half years building rich UIs on top of QGraphicsView and trying every kind of exotic flags or approaches to get better performance results on symbian, I’ve decided to publish some of them which can be useful to game programmers.
With a little help of Ademar, we’ve selected a good use case: a bouncing game.
The game
This game is simple: there are some balls running on the screen, and if you press one of them it will explode, and if a red ball touches a exploded ball, it will explode too. However the game logic is not important here. Lets list some of the characteristics of this game from a developer’s point of view:
- Static background.
- Balls can be implemented as GraphicsItems.
- Red balls are always moving.
- Non-exploded ball doesn’t collide.
- List of elements can grow fast.
- The items are scattered on the screen
The flags
The flags I want to comment on this post are:
The results
* Those tests were performed on a Nokia 5800, type RM-356, with V51.0.006 firmware and Qt 4.6.3.
** The Y axis is measuring FPS: the higher, the better.
10 elements on the screen
First of all, I’ve tried the four ViewportUpdate methods, with 10 items on the screen, and the MinimalViewportUpdate and the SmartViewportUpdate gave me the highest FPS( 34 and 33.5) . Qt documentation shows NoIndex as the best option for dynamic scenes… well, the difference is small for few items, but it’s true =)
So, for the other tests, lets use the NoIndex flag.
What about optimization flags?
I took two results from the latest test (SmartViewportUpdate and BoundingRectViewportUpdate) and ran it again with two optimizationFlags: QGraphicsView::DontSavePainterState and QGraphicsView::DontAdjustForAntialiasing. So, optimizations flags brings us a little bit of improvement when we can control precisely how the items will be drawn.
20 elements
30 elements
40 elements
Lessons Learned
It’s important to select the correct ViewportUpdate method for your kind of scene. It can make the difference.
If there is a lot of dynamic elements, and if they are scattered throughout the scene, it’s cheaper to paint the whole screen (or, at least, the bounding rect) instead of trying to determinate the affected area.
To be honest I was expecting a better result from FullViewportUpdate, but I believe it would be better than BoundingRect if we use non-static background.
What if?
What if I use only one graphicsItem to paint all the balls? What if a ball was not an item but an object with a render method?
I got a little bit surprised, it wasn’t the result I was expecting – it’s worst. It only gets to be better when I put more than 60 items on the screen.
Will I throw the code in the garbage can?
No! As the result of the tests and with a creative help of Nara – INdT designer – I’m releasing a playable alpha version of this game, called by Chubba-Lubba. It’s not finished, since it’s still missing the icon, sounds and scores features, but it’s testable =)
4 Comments