[Kde-games-devel] QGraphicsScene performance

[mauricio at tabuleiro.com]

Fela Winkelmolen wrote:
> Hi, thanks for all the feedback,
>
> I've attached the simple test i did, just click to make a ball appear
(scene.h
> contains some constants to change the basic "settings"). At 13 balls it
> starts to use 100% cpu on my one year old laptop (it was 10 last time
because
> I was using ssh for my kde4 account... realized it only when running
top, and
> yes half of the cpu is used by X)
>
> Setting "export QT_FLUSH_PAINT=1" the result is what you expect it to be.
> I would also think that painting everything manually (like int the
cannongame
> Qt tutorial, I hope you understand what I mean) you get the same
performance,
> or am I missing something? What about using KGameCanvas?
> I mostly discarted openGL/SDL because I thought kdegames don't want those
> dependencies, and I want to write this game as a starting point to
contribute
> to KDE, to learn the KDE technologies and to get to know the community,
etc.

You are right, using SDL is not a good idea for something that is part of
the kdegames package, as it will add several new dependancies. Pure openGL
can be used, but imo it is overkill for a simple game like this: it is
better to use Arthur directly, and it can tap into OpenGL if needed.

OK, I need to exercise my coding a bit before aKademy, so I did some quick
porting here at the hotel in preparation for tomorrow :)

If you want to compare performance of your simple example in QGV against
KGameCanvas, get

http://www.tabuleiro.com/mauricio/balltest.tgz

Remember, I just did a very quick job of porting your pure QGV example to
use it, not optimized at all. Of course, you need to have a KDE4
environment to compile/test this, as kgamecanvas is part of libkdegames.
So go and build a KDE4 development environment, and checkout at least the
kdelibs and kdegame modules. Nowsimply decompress the archive above to
your /kdegames directory.

It will overwrite the CMakeLists.txt file and create a new balltest
directory. You can always use

svn revert CMakeFiles.txt

to undo this change later, and

rm -rf balltest

to finish cleaning all modified files.

Now build the kdegames module and run it, typing

balltest

If you run this simple test, you will see that I used rectangles instead
of squares, simply because there is a KGameCanvasRectangle (used instead
of QGraphicsEllipseItem) and it is easier than using a ball pixmap :)
Maybe you can modify it to use a KGameCanvasPixmap to see if it impacts
performance?

In my test machine the cpu usage is basically 0-10% until I add 35 or 40
rectangles: at this time X starts to eat around 25% of cpu. The balltest
executable remains at 3-4%. This is very non-scientific, but with your QGV
version in the same machine I can only create 15 balls, and X will be
using 75% of the cpu while the executable will take about 12%. With 16
balls in the QGV version I reach 100% of usage. If I try to add 50 balls
it will play at perhaps 2-3 frames per second, using the whole cpu.

With the KGameCanvas version I get 0 to 1% cpu usage (X+game executable)
with 16 balls. With 30 balls it jumps to 6%. With 50 balls it gets to
30%-35% total. For 60% I need 70 balls. 100 balls use 80%, still less than
the QGV version with 15.

So this looks like a game concept that is a candidate to use KGameCanvas,
doesn't it?

Regards,
Mauricio Piacentini