[Kde-games-devel] kreversi_rewrite is almost finished...

[Mauricio Piacentini]

> Ah! Speaking of KMahjongg... For some time I have a question in my mind.
> 
> It is so damn slow on resizing!
> Is this necessary tradeoff for using SVG in general?
> Or is this due to slow implementation of SVG rendering in Qt?
> Or is this due to slow implementation in KMahjongg?
> 
> Just curious :).

Well, the game drawing code is still pixmap-based, there was no change 
in that. It is still the original code, no changes landed in this 
aspect. The problem is that it was never optimized for dirty rects, so 
it redraws all the tiles every time there is a change, even when a 
single tile is simply blinking (like when you request a hint, or enable 
the SHOW MATCHING TILES option.) This was not a problem that many did 
not notice with the smaller game window, but it is more evident with a 
larger playfield. See bug

http://bugs.kde.org/show_bug.cgi?id=62109

So during play time we are now simply revealing an existing issue, and 
this will be fixed with the new drawing code, soon.

However, there will always be a hit when you have to process the SVG 
data to render the tileset initially (tiles are cached from this point 
on). Right now this is not optimized, and it occurs once at program 
startup and once for every resize operation. I do not think this will be 
much faster in the final version, but I plan to add visible feedback 
information to the user so that the process is understood. As a 
comparison, if you use SVG tiles on Gnome mahjongg you get relatively 
the same delay for initial rendering after the resize, so I do not think 
Qt is introducing any major issues here.

On the original KMahjongg there was no resizing, the pixmap tiling and 
caching occurred only once, at startup, and before the game window was 
shown. So users were not aware of this process, it was just compounded 
with the total time to launch the application. But the actual parsing of 
SVG is quick, and adds perhaps one second to the whole process. It is 
just that the initial tiling and caching takes longer if you use larger 
tiles, it is a linear change. The original code used smaller pixmaps, so 
they were created faster. If you set the window size to produce tiles of 
the same size as KMahjongg in kde3 you will find that launch time is 
about the same.

But answering your question im a more direct way, SVG rendering is not 
exactly fast, in any implementation. I believe you will always have to 
parse and cache the svg data in pixmap format, like we do now, but we 
still have a lot of room for optimizations. Even QGV caches as pixmaps 
by default when operating with SVG items, otherwise performance would be 
impossibly slow with anything but the simplest vectorial element.

Regards,
Mauricio