[Kde-games-devel] aKademy 2006 BoF session ideas

[Mauricio Piacentini]

 > I have just been trying one of Andreas' suggestions with the QGV
 > version of KGoldrunner, which was to scale the background tiles
 > and frames for the running men before any drawing is done, rather
 > than scale the whole view.

Just to clarify this to the other readers of this thread, the 
canvas-based code also was implemented with this approach (pre-scale of 
all tiles and frames), as it does not do view scaling. And it makes 
sense to use it anyway, to improve performance. The code in SVN already 
has this.

 > Performance is fine on levels 2 and 25 of the Initiation game, the
 > levels that gave the most trouble.  CPU usage (at 2.4 GHz) is about
 > 3% on level 2 and 15-20% on level 25.  QTimer events are coming
 > in, on average, about 5 msec slower than requested, but are never
 > more than 10% late.  I am still seeing (in my log file) massive
 > re-draws of all tiles within a large bounding rectangle whenever
 > widely separated runners have to move simultaneously, but

 > Performance with the new Canvas class is still much better than
 > with QGV (in that Qt snapshot), making the game playable on much
 > slower machines than mine.  However, Andreas has hinted at some
 > changes in QGraphicsView and X11 that might, in time, alleviate
 > some of the difficulties KGoldrunner has had with QGV.

I am at aKademy, and yesterday Andreas and I spent a couple of hours in 
one of the labs looking at this specific issue. There is no conclusion 
yet, but if you get the KBoard-canvas-base from SVN and run it with the 
QPainter flush code enabled, you will also see full redraws every time 
the user eats a coin and the status bar is updated. If you measure the 
combined cpu usage of X and KGoldrunner the performance gap is not 
really as extreme as I previously reported, not sure why. But something 
is still there, unfortunately.

 > So I'd like to stay with the new Canvas class in KGoldrunner's
 > SVN code and await further developments from Trolltech.  I won't
 > do any further work on the QGV version of KGoldrunner right now.

Yes, the current version is stable with the KBoard-canvas, I agree 
(well, I have to, right? :) ) But after yesterday's debugging session I 
can see that there is something that STILL causes full redraws, even 
with a lighter canvas, and this causes smaller cpu spikes of up to 20% 
if you combine X and KGoldrunner, and this may cause the game to still 
fail on a 500MHz machine for example, or one with a crappy video card. I 
could not explain these yet, but they do not come from QGV (as it was 
the case before Andreas updated the QGV dirty rect management code.) It 
might be a KMainWindow issue even, connected to the status bar. Or it 
might be a Qt4.2 issue. We could not find the source of the issue in the 
two hours we had before Andreas had to leave to the airport.

So I will still investigate this in the future, probably even during 
this week. But you can of course proceed with the current SVN code for 
development, if we need to optimize drawing again in the future (or even 
return to QGV) this is an easy change as the code for this is already 
available.

Regards,
Mauricio Piacentini