[Kde-games-devel] Proposing KGameRenderer

[Stefan Majewsky]

Hi,

my last mail to the restructuring thread included some (mild) complaints about 
the rendering code in most kdegames apps. I've decided to do something about 
it, considering especially that I have to port KDiamond's renderer singleton 
from KPixmapCache to KImageCache anyway.

Looking at all of our games, there are numerous approaches to SVG rendering. 
These differ most prominently in...
...the rendering strategy: Many apps (including KLines, KBattleship) render 
SVG elements into pixmaps, some of which use shared caches (such as KDiamond). 
The other big fraction of apps (e.g. Bovo, Granatier, KBlocks) uses just-in-
time rendering via QGraphicsSvgItem::setSharedRenderer.
...configurability: Most apps do not specify any theme-dependent configuration 
values. KDiamond reads some special keys from the theme file, KBlocks reads 
positions from the SVG file, and the funniest thing is KBlackBox, which opens 
the SVG file as an XML document* to read the style attribute of some elements.

I am quite sure that this kind of diversity is not helpful in any way, esp. 
when code has to be ported to new classes (like in the current case of 
KPixmapCache being deprecated in favor of the less crashy KImageCache). You 
all know that keeping 20 slightly different versions of the same code is 
harmful. (For example, Bomber's rendering code seems to have the solution for 
a rendering problem in KDiamond.)

Therefore, I propose to replace all these renderer classes etc. by 
KGameRenderer (see attached header**). The strategy is as follows:
- Instead of a KGameTheme, a KSvgRenderer and possibly also a KImageCache, the 
app has one KGameRenderer instance (which is probably a K_GLOBAL_STATIC). This 
class loads the theme, instantiates the KSvgRenderer, renders pixmaps and 
saves them in a pixmap cache.
- There is also some basic logic for animated sprites with multiple frames.
- Some internal objects are exposed in the cleanest-possible manner to allow 
app writers to handle their abstruse corner cases. (For example, 
KGameRenderer::svgRenderer() is for KAtomic which needs to compose pixmaps 
from multiple elements.)
- For QGraphicsView-based apps, there is a KGameRenderedItem. That's basically 
the same as a QGraphicsPixmapItem, but it fetches its pixmaps from 
KGameRenderer automagically (e.g. on theme change or resize events). This 
class is designed such that Qt 4.6's animation framework can be plugged in 
there in a few lines of code.

So...
1. Is there interest in having this in libkdegames?
2. If yes, can I haz API review, plz?

Greetings
Stefan

* I'm actually thinking about changing this. Reading the complete XML document 
just to obtain one or two simple flags is just overkill to me. KBlackBox has 
no GHNS and only theme, so slightly changing the theme format between releases 
should be unproblematic.
** Don't worry about the "KDiamond"s in there, the code is in the kdiamond 
source of my kdegames checkout ATM. Also, do not worry about multiple classes 
in one header.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kgamerenderer_staging.h
Type: text/x-chdr
Size: 8517 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20100611/6c2a3917/attachment-0001.h