[Kde-games-devel] Fwd: Re: SVG Rendering speed

Ian Wadham ianw2 at optusnet.com.au
Sat Sep 29 03:57:46 CEST 2007


Re KGoldrunner ...
On Sun, 23 Sep 2007 07:01 pm, Andreas Pakulat wrote:
> There's only a slight delay for the initial
> rendering and I can see the playground being first rendered in
> "half-screen" mode (i.e. its about as large as the select-game-dialog)
> and then after a second it gets fullscreen as the rest of the application.
>
This seems to be as good as I can get it.  It is still doing just one SVG
load and render at startup ... and the Main Window is still giving two
resize events, one of which KGoldrunner ignores.

I do notice a big hole appearing when the initial dialog box closes, even
though you can grab the dialog box and move it around rapidly without
any loss of graphics quality.  And it seems to take far too long for
KGameCanvas/QPainter/QWidget/X (even) to repaint over it, even
though the whole main window has been loaded, rendered and painted.

I believe this is an unavoidable consequence of the way Qt does painting
- or so I was once told by a Qt developer - but is there some way to soften
or reduce the effect?  It's really ugly.  I'm working with *no* graphics
acceleration on a Pentium 4, 2.4GHz CPU with 256Mb RAM.

Re KShisen ...
With QT_FLUSH_PAINT=1 I get *three* full-window flashes every time
I make a move - in different colors.

IIRC, there has been a long delay before displaying the red-line connector
ever since the sliding-move option was brought in, some months ago.  I
think there must be some unnecessary re-painting or re-rendering going
on.  Or maybe it just takes a long time for KShisen to validate the move and
calculate the path of the red-line.

After the red-line appears, the move-animation is very fast and there
is minimal QT_FLUSH_PAINT activity (i.e. minimal re-painting).  I am not
using the sliding-move option BTW.  Hope this helps.

All the best, Ian W.




More information about the kde-games-devel mailing list