FrameSvg: sharing d->frames

[Marco Martin]

On Wednesday 22 September 2010, Aaron J. Seigo wrote:
> hi all (but particularly Marco ;)
> 
> i was doing some digging into pixmap usage in plasma and found a few
> surprises.
> 
> first, libplasma tends to use a _lot_ of FrameSvg object as if they were
> mostly free; they aren't. unlike Svg which is backed quite heavily by the
> cache in Theme, FrameSvg does a lot of local pixmap caching. we need to
> watch how freely we use that class. i manage to eliminate 1/2 the usage of
> them for widgets with focus indicators, so that's an improvement.

uhm, the private focusindicator widget, the qstyle primitive, or..?
anyways, if we cant't reduce usage enough for framesvg itself, we have kind of 
an issue since the themes rely almost completely on it

> i also noticed that in many cases, FrameSvgs are creating and storing the
> same data. making the FrameData objects shared is another good way to save
> on pixmaps, and i have a nearly working patch based on a shared pool of
> reference counted objects. i'll post a review board patch for it when its
> ready, since it is a finicky patch (as any caching tends to be :)

yes, i particularly agree on this point ;)

> finally, we have the PixmapTranstion animation. this thing is used all over
> in Plasma::Widgets, and has a particularly evil behaviour: even when it
> isn't transitioning between states it will generate at _least_ one new
> pixmap that is often simply a copy of the source and/or target pixmaps.
> this is primarly due to the centering algorithm, but also partly to the
> internal caching that is done in PixmapTransition.
> 
> http://reviewboard.kde.org/r/5406/ address this part of the issue. this
> comes at a trade-off: whenever currentPixmap() is requested, it is
> regenerated unless the cache property of the animation is set to true.

ok, looking at it now
 
> the moral of the story is that there is a lot of headroom for improvement
> on pixmap usage in plasma, it seems, and as we do more and more fanciness,
> we should keep an eye on it.
> kdumppixmap has been key to my work on this, so kudos to its author(s).
great tool indeed

-- 
Marco Martin