[Kde-games-devel] SVG Rendering speed

Ian Wadham ianw2 at optusnet.com.au
Thu Sep 27 00:51:34 CEST 2007


On Thu, 27 Sep 2007 07:12 am, Andreas Pakulat wrote:
> As I already stated elsewhere in these threads I don't have a problem
> playing any of the games, its really just re-rendering when the size of
> the window changes. This even works quite well as long as the window is
> small. For example ksudoku (btw, I love this one, so nice to have it in
> kde4) starts up pretty small and dragging it larger it resizes rather
> fast for the first few dozen pixels. Only when it reaches a certain size
> the re-rendering of the board gets slower and slower.
>
There would have to be some inescapable mathematics here.  The
area to be re-drawn/re-sized would go (roughly) as the square of
the width, so you should expect things to slow down at larger sizes.
Twice the width requires four times the processing.

The question bothering me is what are the weakest (slowest) links in
the chain of graphics classes the various games are using?  I think
there could be several answers, depending on circumstances.

For example (I am guessing here, but I have done *some* timings
of various steps in the process), SVG load and SVG render seem to
be sensitive to size of .svg or .svgz file, which maybe means "level
of detail" in the Inkscape drawing.  Perhaps there is some
non-linearity in the way Inkscape organises its XML output (e.g.
size of file is proportional to some power of the number of objects
in the drawing).

One thing I did notice is that loading and rendering the Geek City
background in KGoldrunner speeded up significantly when I
converted it to a .svgz file, though that may have been a fluke
(I was making a lot of other changes at the time).  When I get a
moment (which is not now, unfortunately), I would like to do some
"before and after" timings on compressing "Treasure of Egypt".

There also seems to be a pure-QPainter or pure-X component in
all this, as Mauricio notes re KSudoku.  I noticed it when trying to
improve the timing of the (pure black) fade-out/fade-in component
of KGoldrunner.

In concluding, let me say this.  I really do not think it matters much
if it takes half a second or two seconds to re-size or to change
themes, just so long as it is not 10 or 20 seconds or longer ...

More important, I think, is to avoid ugly graphics effects on the
screen while the resize or theme change is in progress.  ATM
I do not know how to achieve that.

Cheers, Ian W.


More information about the kde-games-devel mailing list