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

[Luciano Montanaro]

Il Saturday 19 January 2008 18:32:20 Andreas Pakulat ha scritto:
> On 19.01.08 17:00:26, Luciano Montanaro wrote:
> > Il Saturday 19 January 2008 13:52:35 Andreas Pakulat ha scritto:
> > > On 19.01.08 21:37:25, Ian Wadham wrote:
> > > > On Sat, 19 Jan 2008 07:22 pm, Andreas Pakulat wrote:
> > > > > On 19.01.08 14:18:30, Ian Wadham wrote:
> > > > > > I think the approach can be used in any KDE 4 game and probably
> > > > > > in other apps that require substantial graphics processing during
> > > > > > startup. I think it will also work if the main window library
> > > > > > code gets changed, though I see no signs of that happening in the
> > > > > > TechBase TODO lists. Any comments or feedback?
> > > > >
> > > > > a) Great Work.
> > > >
> > > > Thanks Andreas ... :-)
> > > >
> > > > > b) Where's the patch or branch?
> > > >
> > > > It's rev 762565 of kdegames/kgoldrunner on trunk.  Previous rev
> > > > of KGoldrunner was 762169.  Rev 762565 involved small changes to
> > > > the three main classes (6 files): main widget, canvas and game.
> > >
> > > Thanks, I'll have a look later tonight.
> > >
> > > 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.
> >
> > Yes, we have talked about using pixmap caches for the svg graphics...
> > However, I'm not sure it is really needed, for all games, and for all
> > graphics.
> >
> > 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.

 
> > Uhm, the cards are loaded in a thread in kpat; so KPixmaps cannot be
> > used. :(
>

I meant QPixmaps, sorry.

> 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...

Because QImage is a QPaintDevice subclass, QPainter can be used to draw 
directly onto images. When using QPainter on a QImage, the painting can be 
performed in another thread than the current GUI thread, that is except 
rendering text (because QFont is GUI dependent). To render text in another 
thread, the text must first be derived as a QPainterPath in the GUI thread.

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

> > 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. 

> 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?

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.

A different approach could be to render all the cards on a grid on a single 
large pixmap, and load/save that instead. *IF* the card rendering really 
takes too much time. 

Luciano