[Kde-games-devel] Proposing KGameRenderer

[Stefan Majewsky]

On Saturday 12 June 2010 10:40:26 Ian Wadham wrote:
> 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.

That's why I want to get it right once, and have all games benefit from this. 
There are dozens of rendering implementations right now, and going through all 
these implementations, one should be able to identify both outdated hacks and 
real performance improvements which all games can benefit from.

> If SVG loading and rendering were faster, we would not need caches ...

No. The main problem is that rendering 100 graphics primitives on screen in 
each paintEvent is less efficient than doing it once off-screen, and then 
rendering the result in one graphics primitive.

> 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".

It is broken from the viewpoint that the rendering is not as efficient

> 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.

KGameRenderer did already reload the SVG only when the theme changes. I have 
now changed the behavior such that the SVG is not loaded if the cached theme 
is the one we want, and the cache contains everything we need. (Thanks to the 
flexibility of KSharedDataCache, frame counts can also be cached.)

> 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).

That seems to depend on the theme complexity. KDiamonds' default SVG loads in 
60ms here.

> > - 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 ... :-)

KGameRenderer::setFrameBaseIndex is in my working copy now (although it's not 
recommended for new apps). I'll update the diff on ReviewBoard after having 
fixed some smaller bugs I just encountered.

> See above comments.  Also I think the doco needs more explanation
> somewhere of how loading, rendering and retrieval times will be optimised.

You mean e.g. why using KGameRenderedItem is more efficient than 
QGraphicsSvgItem with a shared renderer? I can surely expand on that. I plan 
to write a blog article on the design of KGameRenderer, and an excerpt will be 
embedded in the apidox then.

Greetings
Stefan