[Kde-games-devel] KGameCanvas

[mauricio at tabuleiro.com]

> Personally I'd like to receive brief answers on questions like:
> 1. In what situations this class is a better choice than QGV?

In general, in situations where you are currently using drawPixmap() and
want a better management of screen redraw, but does not want to use QGV
structure for one reason of another. Or if you are running into an issue
with the current QGV feature set, like the lack of ability to invalidate
partially the background cache, which was hurting KGoldRunner. This
feature is scheduled for 4.3, btw, Andreas confirmed it to me during
aKademy.

> 2. What criteria one should use when choosing QGV or KGameCanvas?

I would say that you should use QGV as your first choice. Specially if you
do not understand the differences yet. Kpat for example is using it, and
KReversi as well. IMO you should consider using KGameCanvas for situations
where a bug or design structure in QGV does not let you achieve optimal
performance for your game, and you fell you can benefit from a more direct
QWidget subclass, with only basic functionality. You can only feel this
usually after at least trying to implement the QGV version. Like any major
framework it may not fit your needs exactly, and in some parts of it are
not easily modifiable via subclassing.

> 3. What are the pros/cons of each one?

In a perfect world, you would just use QGV. If you (like me) however have
just realized that you have spent a lot of time trying to fit QGV into
your game structure just to draw simple pixmaps, and still are not getting
optimal performance, then there is no much sense using it, just go for a
direct QPainter-based solution.

BTW, the KGameCanvas class is still under development. I found out that
for kdegames needs we need some additions, methods to delete and remove
members explicitally, for example. Maurizio mentioned using it in KBoard
with Boost smart pointers, maybe that is the reason why these are not
readily available.

Regards,
Mauricio Piacentini
Tabuleiro