[Kde-games-devel] QGraphicsScene performance

[Ian Wadham]

On Sat, 30 Jun 2007 05:59 am, Fela Winkelmolen wrote:
> 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").
>
Congratulations on such an elegant demo, Fela.  I don't think you
could be doing anything "wrong" in your code re use of QGV.  It is
so simple and minimal ...  Nice work!

> At 13 balls it starts to use 100% cpu on my one year old laptop ...
>
On my Pentium 4 desktop, 2.4GHz, I got about 17.  BTW, 20 msec
is a rather short time-pulse as KDE Games go.  I tried upping it to
50 msec and doubling the dx and dy values.  Then I was able to
get 25 balls going, but with some jittering.  That could be less obvious
in a real picture (with less contrast) I would guess.

> I would also think that painting everything manually (like in 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?
>
Direct use of QPainter is an option and it should always be faster than
QGV or KGameCanvas, but you would have to do your own house-
keeping, which could be rather complicated if your Breakout game gets
to be anything like the video of BreakQuest at nurium.com, and I hope
it will ... :-)

What do I mean "house-keeping"?  Well, all the actual painting has to
be done in a QPaintEvent, at a time determined by Qt, but the need to
paint, repaint, explode a brick, etc. tends to come up elsewhere in the
game's logic, so you must make a kind of shopping list of all the things
to do next time there is a QPaintEvent and keep track of that yourself,
including erasing things and re-painting bits of background.

Roughly-speaking, I think that is what QGV and KGameCanvas do
*for* you: QGV in a very general way and KGameCanvas in a simpler
"lightweight" way (please correct me if I am wrong, Maurizio).  QGV,
for example, accepts a scene of arbitrary size and allows you to have
an arbitrary number of views (actual painted graphics) into that scene:
and the views can be clipped, scrolled, rotated, scaled, etc.

With such generality comes overhead (of CPU time or RAM usage),
in my experience (I am an old real-time programmer from way back).
And overhead can be deadly to time-critical code, such as animation.
On the other hand, if the overhead is acceptable, you can save yourself
a lot of time and trouble by using the general-type software.

In the case of KGoldrunner, KGameCanvas has acceptable (actually
undetectable) overheads, but QGV does not.  Other games find QGV
performance acceptable.  For KBreakOut you must make the choice.

If you encapsulate sprites, etc. in their own classes, as Mauricio did
in KGoldrunner, it should be easier later if you must change your mind.

> I mostly discarded 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.
>
Good thinking, but KDE does allow new libraries and technologies to
be assimilated all the time, after some discussion and consensus. :-)

In KDE Games in the last year we have been assimilating SVG, GGZ
and KGameCanvas, as well as all the new stuff that comes with KDE4.
And KDE Edu is using a library called Avogadro  for 3D visualisation of 
molecules, see http://www.commit-digest.org/issues/2007-05-20/
(third story).  But I think these are all examples of things we could not
do well with the technology we already had.

All the best, Ian W.

P.S. FYI, Fela, Maurizio (Monge) is the author of KGameCanvas and
Mauricio (Piacentini) is a genius from Brazil.  Take a bow, guys!