[Kde-games-devel] Proposing KGameRenderer

[Ian Wadham]

On Saturday 12 June 2010 5:02:24 am Stefan Majewsky wrote:
> 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.
>
BTW, why do you "have to port"?  I see that KPixmapCache is deprecated
now, but retained for backward compatibility, and that most of the uses of
it are in games, though there are some other uses in prestigious apps
such as Amarok and Kalzium.  Should we all be porting?

> 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.)
> 
Knowing the history of all this, I imagine that during the exciting(?) era of
conversion to KDE 4 and SVG, each author fought the many unknowns and
inefficiencies in SVG rendering in his or her own way.  I certainly did. :-(

In that era, we were never able to arouse any interest in core developers
and trolls improving the efficiency of KMainWindow, QMainWindow and
QSvgRenderer.  Re the latter, maybe it is the whole SVG/XML thing
that begets huge SVG files and slow loading and rendering times.  If
SVG loading and rendering were faster, we would not need caches ...

Games were particularly vulnerable to slow loading and rendering times,
some more than others, so some people used caches and some did not,
for example.  There were also many views on how an SVG file should be
organized ... and still are ...

> 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.
>
This is a fine idea and one which should be easy to adopt in several
games, provided we just have to delete existing code and replace it with
a small amount of new code which carries a small risk of introducing new
bugs.  Anything complex, however, is likely to encounter thinking along
the lines of "if it ain't broke, don't fix it". 

There seems to be a hidden assumption here that the order of events
at execution time is always create a KSvgRenderer, load SVG, render SVG,
cache (if necessary for timing) and thereafter use the cache until the theme
or the picture-size changes or the run terminates.

I would suggest that the creation of a KSvgRenderer, SVG loading and
SVG rendering can all be postponed until it is found that there is no cache
or that it is invalid (e.g. SVG file more recent than cache) or that there is 
no cached pixmap with a required identity and size.  Also, loading is needed
only when there is a theme change, as opposed to a size change.
KGoldrunner::KGrTheme does that (i.e. it uses the cache alone in many
runs of KGr) and that saves a *lot* of startup time (after the first run).

> - There is also some basic logic for animated sprites with multiple frames.
>
Could there be a way to set the frame origin as well as the suffix?  I would
not wish to have to re-label all the sprite IDs in SVG files in KGoldrunner to
start at zero (they currently start at 1).  Nor would I wish to add dummy
zero-elements to all SVG files, with a possible risk of them being deleted
in future as having no apparent purpose ... :-)

> - 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.
> 
This seems to be a very good idea.  It might even make it easier and less
risky to convert certain games to QGraphicsView ... :-)

> So...
> 1. Is there interest in having this in libkdegames?
>
Yes.

> 2. If yes, can I haz API review, plz?
> 
See above comments.  Also I think the doco needs more explanation
somewhere of how loading, rendering and retrieval times will be optimised.

Thanks, Stefan, great work.
Ian W.