[Kde-games-devel] QGV repaint and update performance

[Ian Wadham]

Yo Mauricio,

You truly are a human powerhouse !  I hope you found some time
to enjoy the Carnaval !

On Wed, 21 Feb 2007 03:54 am, Mauricio Piacentini wrote:
> Mauricio Piacentini wrote (twice):
> >> Martin Heni wrote:
> >> However, why this is is totally unclear to me. This must be some QGV
> >> problems. Maybe just hope for a new Qt release. Does anybody know
> >> whether Trolltech is aware of these issues?
> >
> > Yes, they are. See my reply to Tomas, we discussed and tried to address
> > this before last aKademy, and Andreas (from TT) even looked at
> > KGoldRunner specifically in Dublin.
>
> Just a disclaimer: I am of course not 100% sure at all that the current
> issue we are seeing in this case (KWin4) is the same we observed in
> KGoldRunner back in Sept/Oct, just that it seems to be. It may very well
> be that this is already solved in Qt4.3, or that we happen to share a
> bug in the game implementation that was causing that problem and this
> one as well ... <snip>
>

Re KWin4, I am running a 2.4MHz Pentium 4 on a quite old copy of
the program (updated last weekend).  I get no jumpy behaviour, but I
do get 40+% CPU in X.  The startup animation gives a "wiggle" when the
two lines of pieces are about to meet and move into a circle.  The leading
pieces turn left briefly and then right continuously.  A small code blemish?

Lateral thought: if the game animation works OK, maybe the startup could
play two or three rounds of actual games as a demo (click to stop at any
time), if that is not too much extra programming.  I think it is great to have
something to attract interest and involvement when a game starts up.

Vertical thought: re QGV and KGoldrunner.  In KDE3, KGr is based very
heavily on the QCanvas library of Qt3, especially the sprite and tiled
background facilities, which have been dropped or downgraded in QGV.
The entire play area is covered with small background tiles and sometimes
a tile is re-drawn, as when collecting gold or revealing a hidden ladder.
The runners (sprites) move around in front of all that, all the while changing
their pixmaps (animation frames).

In QGV with X11, background items are cached in the X11 server.  Updating
a background involves to-ing and fro-ing with the server, with high CPU costs
both ends.  This is not a problem on Windows or Mac, Trolltech say.

If a large area of background containing numerous items has to be updated,
the CPU costs become extreme (at the 50-100 millisecond timescale) and
animation becomes jerky or slows right down, which is what happened to
KGr initially.  In one case there were three enemies and the hero moving,
three of them picking up gold and re-drawing background tiles and spread
over widely-separated parts of the play area.  In another case there were
25 enemies moving and fanning out over the play area (which might be
something like the situation in the KWin4 demo).

The problem was increased (IMHO, though I do not think TT always agreed)
by QGV's algorithms for deciding what parts of the scene to re-draw.  I think
they tended to over-estimate in some ways.  By far the most extreme case
was where, if it had 20 things to erase or re-draw, it would update _every_
item within the bounding rectangle of the items that changed.  In the cases
described above, that could be one third to one half the play area to be
re-drawn between animation frames (50-100 msec).  QT_FLUSH_PAINT
reveals dramatically when this kind of thing happens.

Last time I looked at the code in QGV (November?), Trolltech had dropped
the "20" rule.  They said they would look at other QGV improvements in the
Qt 4.3 timescale and would contact XOrg re improvements in the QGV/X11
interface.  Mauricio and I do not know what has transpired, because M. has
converted KGr to use KGameCanvas and has put KGC in libkdegames.
For what KGr wants to do, KGC is as good as or better than QCanvas was.

I still think KGoldrunner could be made to go fast enough in QGV, by making
all the gold pieces and hidden ladders into foreground sprites, so that the
background tiles would need to be re-drawn only when loading a new level.

However, changing back to QGV is _very_ low on my list of priorities.  Among
other things, it would involve re-testing about 200 KGr levels, several of
which are time-critical.  Pleasurable as that might be, it would take several
days and hours ... ;-)

Right now I am concentrating on making KGr fully SVGized, resizeable and
themeable ... :-) ...

All the best, Ian W.