[Kde-games-devel] SVG and MainWindow resize handling

[Mauricio Piacentini]

Andreas Pakulat wrote:
> However, it does use QImage normally to store the actual data, so
> there's the overhead of one QImage->QPixmap conversion when using it.
> 
> I think we really need to do some profiling, with different approaches.
> I'll try to implement kpat+cardcache tomorrow and see what data that
> gives, compared to the current kpat implementation.

As far as I remember, we are not rendering directly to a QPixmap due to 
more than one reason. These MIGHT be: not able to paint outside 
paintEvents on QPixmaps, X Server caching, and/or problems with correct 
rendering of alpha channels. However, it has been some time since I 
tried it, so the situation might have changed. Maybe you could research 
this a little bit with one game and post the results if there are better 
ways to do this rendering?

I do not want to sound harsh, but there appears to be an assumption on 
some messages of this thread that people were just sloppy with coding of 
SVG support in games, and I know that this was not true. As an example, 
Andreas suggested:

--
Unrelated question: Do the svg games already use KPixmapCache for
caching the rendered svg's? IMHO that could speed up re-resizing the
app, i.e. if you change from maximization to "normal" size and back, as
in that case it would only reload a QPixmap instead of rerendering the
svg.
--

This is exactly what is already done in several games like KMines, 
KMahjongg, etc. It is easy to verify by simply maximizing and minimizing 
KMahjongg, you will get instantaneous redraw due to the usage of the cache.
So do not blindly assume sloppy coding, please :)

KGoldrunner for example revealed a huge number of issues in QGV during 
the initial port. Some are still in the queue for 4.4, see for example

http://labs.trolltech.com/blogs/2008/01/08/accurate-update-regions-for-thin-qgraphicsitems/

This is an update problem we (Ian and me, and Maurizio) found 18 months 
ago, during the initial port of KGoldrunner to QGV (large number of 
sparse items cause big redraw regions.) That is btw the reason why it 
still uses KGameCanvas. It is nice to see that it could be potentially 
solved soon.

Regards,
Mauricio Piacentini