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

[Andreas Pakulat]

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

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.

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

Andreas

-- 
Your lover will never wish to leave you.