Re: scalable icons vs icon caching

[Rodney Dawes <dobey novell com>]

How would this affect themes that pre-render the SVG icons to
PNG files for certain sizes, to work on desktops that don't
support SVG, or support it rather poorly? For instance, in Tango,
we have a configure option to enable pre-rendering PNG files, so
that we will look much better on KDE 3.x. Due to the large number
of compatibility symlinks, and the pre-rendering, the icon cache
for Tango is already quite large. How much larger is this going to
be, considering it would presumably be doubling much of the caching?

Should we perhaps add some smarts to point symlinks at the cached
object that the symlink points to on disk, rather than caching the
same item multiple times? And, if an SVG is pre-rendered at the
sizes you want to add caching for, not render and cache the SVG at
that size, since the theme should be returning the PNG anyway?

Also, are you planning to do this for both GTK+ 2.8 and HEAD, or
just HEAD?

-- dobey


On Wed, 2006-02-22 at 23:49 -0500, Matthias Clasen wrote:
> Scalable (svg) icons seem to become more and more the norm
> in our icon themes. While this is nice in principle, it seriously
> defeats the icon caching in GTK+. For raster icons (png or xpm),
> the mmapped icon cache allows all apps to share the pixel data,
> and keep only a single copy of it in memory. But svg icons have
> to be rendered at the size the application requests, and thus
> every application has one (or possibly) multiple copies of the
> rendered icon in memory.
> 
> I'm currently considering to make gtk-update-icon-cache store
> pre-rendered versions of svg icons in common sizes in the
> icon caches. This would have the negative effect of making
> icon caches somewhat larger. But it would allow apps to share
> the pixel data again, and we avoid rendering the same svgs
> over and over in every application.
> 
> Comments ?