[Kde-games-devel] QGraphicsScene performance

Ian Wadham ianw2 at optusnet.com.au
Fri Jul 6 00:27:36 CEST 2007


I find that KGC is still faster than QGV on the balltest2 benchmark ...

On Mon, 2 Jul 2007 09:30 am, mauricio at tabuleiro.com wrote:
> Fresh updates directly from Glasgow :)
>
> Yes, different update algorithms and policies apply to different
> applications, and previous versions of QGV pre-4.3 really did not perform
> well in some cases. But there is one new addition in 4.3, the
> QGraphicsView::setViewportUpdateMode() method. This is something that did
> not existed before, and it is a way for applications with specific needs
> like games to change the update algorithm, or even to disable it
> completely and handle this directly in your code. So in the case of the
> sample app made by Fela, we could now (in 4.3) use:
>
> View view(&scene);
> //comment this out if you want to use OpenGL to draw the view
> //view.setViewport(new QGLWidget);
> view.setViewportUpdateMode(QGraphicsView::FullViewportUpdate);
> view.setOptimizationFlags(QGraphicsView::DontClipPainter|QGraphicsView::Don
>tSavePainterState);
>
> I also modified the sample code to use a QGraphicsRectItem, so it can be
> more readily comapared to the KGameCanvas one. And there are big and great
> news: if you overide the default update method and set it to the new
> FullViewportUdate then it will behave more or less like the subclassed
> version we had in KWin4 (which btw came from a tip from Maurizio Monge).
> In the case of this particular test app, this means that we can now add
> 100 items instead of the 15-20 we had before, and cpu usage will stay at
> around 20% instead of going though the roof!
>
> Try it from http://www.tabuleiro.com/mauricio/balltest2.tgz
>
Erm ... I don't wish to rain on your parade, Mauricio, but your QGV version
of balltest2 seems to have a longer update_interval setting (40, rather than
20).  When I set both versions of balltest2 to 20 msec interval, KGC is still
faster than QGV, more consistent in CPU usage and has faster response
to mouse clicks under peak load.  Specifically, on a 2.4GHz Pentium 4:

    KGC  80 balls  CPU 96-99% --- QGV 70 balls  CPU 88-99%

> Well, with the new update flags in QGV 4.3 the result is actually
> reversed, and QGV is using LESS cpu than KGameCanvas for 100 items.
>
I beg to differ ... :-)  KGC is still more efficient than QGV in CPU usage on
the balltest2 benchmark.

> Among the things that Andreas said he was
> considered working on, one is particularly interesting for us: better
> support for partial invalidation of the background cache, specially to
> support the need of game authors like in the case of KGoldrunner, where
> we want to invalidate only some tiles, and not the full background, and 
> still be able to use the tiles. So it appears things will only get better
> with 4.4 and on.
>
I had an idea at one stage of changing KGoldrunner so that it does not
need to update the background.  Basically, all changeable tiles (gold,
hidden ladders and bricks being dug) would become "sprites".  All other
tiles and the themic background would stay static in the background
until a change of level.  I think the KGC version already does something
like this.  Anyway, when I have some time, I might try an upgrade of the
balltest2 example to include a background and some semi-static sprites.

> aKademy is already paying off for us, guys :) Now let us all experiment
> with this new options to see how they work in each case.
>
It's great that you can meet the authors/designers of libraries at
aKademy and compare notes.  I hope to be there next year! :-)

All the best, Ian W.


More information about the kde-games-devel mailing list