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

[Ian Wadham]

My previous message was intended as input to the BoF
session.  Basically, KGoldrunner *can* run OK with QGV
as it stood at 060830 snapshot.  It will probably run better
with later versions of QGV - or more recent ones than I have.

KGoldrunner runs *really* well with the lightweight Canvas
class, but that is probably not enough reason to put the class
in a KDE library.  Do other KDE games and apps need it?
Maybe KStars?

Mauricio wrote, re fill re-draw "every time you eat a coin":
> 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.
>
I have not noticed any hiccups during actual play with the new
Canvas version.  But as you point out, Mauricio, they could occur on a
500 MHz machine ... maybe CPU spikes always have occurred, with
KDE 3 and QCanvas, but I've not had any performance-related bug
reports and have not done any performance measurement before.

We had some funny debugging output from a thing called Accelerator
Manager (IIRC) soon after you had originally converted KGr to QGV,
Mauricio, but it went away.  It's possible that KMainWindow *is*
being over-zealous in its re-draws when we update the status bar (to
keep score).  Could there be some tiny overlap of status bar and
play area, or one that KMainWindow "imagines" is there due to the
way it calculates things?  I guess we'll have to wait and see, when
Qt and KDE are more stable.  Meanwhile I'm just hypothesising ...
What happens if we eat a coin but don't update the status bar to
keep score (disable signal)?  Do we still get the full re-draw?

All the best, Ian W.