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

[Luciano Montanaro]

Il Monday 21 January 2008 00:51:04 Andreas Pakulat ha scritto:
> On 19.01.08 23:08:01, Andreas Pakulat wrote:
> > On 19.01.08 19:12:15, Mauricio Piacentini wrote:
> > > 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
> >
> > That one for sure not, you can create a QPixmap, paint on it and then
> > save it to a file without problem.
> >
> > >, X Server caching, and/or problems with correct
> > > rendering of alpha channels.
> >
> > I highly suspect this last one, as QPixmap doesn't let you specify the
> > format of the image wrt. alpha channels.
> >
> > However, the cardcache I've written on top of KPixmapCache still renders
> > svg's itself (because KPixmapCache has no way of defining the element in
> > the svg when letting it load the svg) and thus still uses a QImage as
> > "first" image source. The same happens for pngs, which are read into a
> > QImage and that one is then transformed to fit the requested size. Only
> > after that the image is converted into a pixmap and stored in the cache.
> >
> > > 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?
> >
> > OMG, I really need to stop being sucked into all kinds of things :) As I
> > said, I'll try to add the pixmap caching to kpat tomorrow and see
> > wether/how that improves speed at startup, changing decks and resizing.
>
> Ok, so after 2 hours of hacking I have kpat using the CardCache class
> I've written. Unfortunately KPat is totally useless with this. I don't
> yet know why, but for some reason the rendering of just a single
> frontside takes multiple seconds. I suspect I'm using the svg renderer
> in a wrong way, or maybe its really the parsing of the svgz (currently
> done for each request to render a frontside).
>

I don't know how you are using the svg renderer. You definitely want to load 
the svg data once and render the various elements from the single instance.

The parsing is done on load time, after that, rendering from that is roughly 
equivalent as drawing a QPicture.

> So this just means that I'm back to pen&paper for the card cache, doing
> a bit "premature" optimizations (like re-using the svg renderer,
> introducing threading via ThreadWeaver) and creating a real testcase
> scenario for it.

Threading is not going to help if you do not have multiple cores...
Reusing the same renderer instead is important, and it's not at all a 
premature optimization. It's simply using it as it is meant to e used. :)


> I'll keep you posted about the progress on this, in a separate thread.
>

Great, let us know how things proceed.

Luciano

> Andreas