xrestop and Amarok's pixmap usage

[Thomas Lübking]

Am Sunday 07 February 2010 schrieb Seb Ruiz:
> Is there a method of determining how much memory the SVG rendering is
>  using?
> 
KPixmapCache limits to 3MB by default, but there're some scaled svg's in use 
(the splitters) which will scale the res usage with the window width.

First thing i noticed is that apparently the plawigadgets (stuff in the 
context view) don't wipe their stuff (esp. webkit, i.e. the wp applet)

Next thing is that the pixmap usage is (for all Qt apps) heavily windowsize 
dependent, so "Amarok uses a huge amount of pixmaps" is a bit unsharp ;-)

And then:
One little inefficient sucker is the custom slider ;-)
(I just noticed this while trying to get it rtl aware)

Basically we have a tiling slider:
(================)
with a tiling filled part
[-------o
but the mid part is not painted QPainter::drawTiledPixmap() but the full size 
slider is (stretched) rendered into a pixmap, cached and then painted once 
until it's rerequired when the slider is in the same position the next time 
:-\ (So the growing slider fills the cache and increases pixmap usage)

The funny thing is that for some cache conditions this makes the entire 
caching useless =D

There're 3 options to handle this.
------------------
1. Tile:
define the mid slider parts to be tilable and render them repeating with a 
32px or 64px width per tile

2. Scale & Crop:
define them to be stretchable but unisize, what basically means that the 
filled part has the fixed width of the entire slider and is painted clipped 
from left to right.

3. Scale:
Live with it (no restrictions, the slider will grow stretching like e.g. 
oxygens progressbars - though it currently doesn't make use of this and it's 
pretty inefficient)

2&3 have especially issues on resizing because one triggers _many_ 
regenerations in a short time flooding the svg renderers pixmap cache.

3 is a real mem hog and actually the progressing slider shouldn't use the 
cache at all (easily triggers too many regenerations) it's also expensive on 
the cpu.

If we find that 2 or 3 is necessary, clustering should be a nice way to deal 
with this, i.e. you don't create a pixmap for every width, but for e.g. every 
n*16 width cluster and paint it center aligned (with max. 7px error on each 
side)

To prevent it from polluting the cache on e.g. resizes, skip caching for:
- the groove (there's only one relevant constant size)
- the progress in case of (2) as above holds as well

Cheers,
Thomas