[Kde-games-devel] QGraphicsScene performance

[Jeremy Wick]

On 7/9/07, Fela Winkelmolen <nimatar at gmail.com> wrote:
> > view.setViewportUpdateMode(QGraphicsView::FullViewportUpdate);
>
> This seemed to make most of the difference, unfortunately it becomes a lot
> slower when there are also a lot of not moving objects (like the bricks in
> kbreakout), which are repainted unnecessarily, maybe this could be worked
> around making it part of the background and caching the background or
> something... but I'm not sure. Anyway, I'm trying to write the code in a way
> it's easy to switch painting system (not that I did much lately, mostly due
> to exams and laziness...).

Yes that would be a good idea. In fact it reminds me of a previous
project i had.

I developped a Bomberman clone in J2ME for mobile phones but i ha no
phone to test it so i ran it on an emulator. The performance was fine
with 32x32 boards, AI, animated sprites, etc ..
Two days before presenting the project one of my friends lend me a
Nokia phone with a JVM ... but on the real thing the performance was
terrible (~5 fps).
So 10 minutes of profiling later i realized that calling the method to
pain a sprite was expensive, so i did just that
- render all the fixed sprites into a buffer (such as the floor and
walls/blocks)
- animated sprites were rendered on top of this in a second buffer
Obviously this was a lot faster and ran at the same speed as the emulator did.

Basically you would always want to limit the number of sprite you
paint so of course repainting a hundred bricks for each frame is a
waste, if you just repaint (background+brick), player and ball it
would be better.


-- 
WICKERSHEIMER
Jérémy