[Kde-games-devel] Proposing KGameRenderer

[Luciano Montanaro]

On Sat, Jun 12, 2010 at 10:40 AM, Ian Wadham <iandw.au at gmail.com> wrote:


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

For what is worth, I did a few experiments bach in the day, and
loading and rendering an svg xml seemed to add little time, compared
to loading a serialized QPicture (a serialized representation of the
rendering operations).
So the problem of vector graphics versus pixmaps is simply that
drawing multiple overlapping polygons takes more time than blitting a
pixmap.

Regarding the main point, about unifying the rendering code... I'm
with Ian here: if it is not broken, do not fix it.

In particular, we have a few games that, simply put, work. They are in
maintaince mode, essentially, and what would we gain by "fixing" them
when they actually work well?

If you are working on a still evolving game, please go ahead with your
classes, and maybe they are worth of being put in a shared library.

But this restructuring is not going to be noticeable by players
(except for, maybe an improved startup), while there are tons of
features that could make them happier, and are not too hard to
implement.

For example:

- KNewStuff3 for themes and levels
- sound support in all games
- more animation and "bling"
- in game Tutorials
- Usability review and interface streamining





-- 
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams