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

[Andreas Pakulat]

On 19.01.08 19:06:38, Luciano Montanaro wrote:
> Il Saturday 19 January 2008 18:32:20 Andreas Pakulat ha scritto:
> > On 19.01.08 17:00:26, Luciano Montanaro wrote:
> > > For example, loading card graphics in Qt svgviewer is almost
> > > instantaneous here. Loading them in KPat seem to take longer...
> >
> > Here I don't see a noticeable difference.
> >
> I do, here. But I have an intel card. Can you try loading a deck of card in qt 
> svgviewer, and switch between painting on image/pixmap? Is there any 
> difference? Here the difference is noticeable. For Tigullio international,
> less than 1s "native" rendering, 
> around 3s "image" rendering.

Loading with "image" takes about twice as long as the "native" one.

> > Huh? It already uses QPixmap (there's no KPixmap). Or are you saying
> > that KPixmapCache cannot be run in a non-gui Thread? Do you have some
> > data to back that up - the API docs don't talk about that. And the
> > QPixmap docs also don't say anything about this.
> >
> 
> Here is the excerpt from the qimage page...

Uhm, but that doesn't say anything about QPixmap at all - at least as
far as I can see. Also QPixmap is a QPaintDevice the same as QImage.

> So, it looks like QPixmaps can only be used in the main thread. Maybe it is 
> platform specific, though.

I don't see that anywhere mentioned (except that you need to translate
text into a painter path before doing the painting). Also I'd be quite
surprised if this would be platform specific, AFAIK kdegames work on
win32 as well - so that covers windows and X11 and I'm actually not
aware of any other windowing system that KDE supports.

> > > However, just for a quick test, I tried disabling the cache code...
> > >
> > > Here using the cached pixmaps seem to actually slow down kpat startup.
> >
> > Well, the caching in KPat is rather simple, it really only saves the svg
> > rendering. But it also has quite a lot of qpixmap<->qimage conversions
> > which may slow down everything. See my other comment lately here.
> >
> 
> Yes, well, what it looks like, at least on my hardware, is that in this case 
> the cache is counterproductive. 

Yeap, however IIRC if we add the cardcache I've proposed we can
eliminate quite some of the conversions. For example, there's a
conversion done on _all_ pixmaps which scales the pixmap to the actually
wanted size right before its returned (dunno the function name atm).
This is simply stupid to do for svg decks, as they already have the
right size.

> > Hmm, did anybody ever tried profiling the card games (lskat/kpat for
> > starters) and check where they spend the time when rendering.
> >
> > Andreas
> 
> Can you try the patch attached to my last mail, defining and undefining the 
> USE_PIXMAP_CACHE macro?

I'll try it later, first some dinner and dvd :)

> The fact is that having to load 52 files and decompress them may well take 
> longer than loading one simple file and rendering it directly.

Hmm, looking at KPixmapCache, it doesn't really load 52 files, it seems
to uses mmapping of a large cache file. Which means the file itself is
probably already open. It also uses qCompress/qUncompress which should
be a rather simple and quite fast compressing algorithm. 

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.

Andreas

-- 
Good news from afar can bring you a welcome visitor.