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

[Andreas Pakulat]

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.

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

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.

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

Hmm, did anybody ever tried profiling the card games (lskat/kpat for
starters) and check where they spend the time when rendering.

Andreas

-- 
Is that really YOU that is reading this?