Re: scalable icons vs icon caching

["Matthias Clasen" <matthias clasen gmail com>]

On 2/23/06, Rodney Dawes <dobey novell com> wrote:
> 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?

Well, if the prerendering is already done on disk, gtk-update-icon-theme
doesn't have to render additional versions, thats great.

> 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?

gtk-update-icon-cache is already smart enough to store the pixel
data for each icon only once, and handle symlinks by storing
crossreferences in the cache, if that is what you are alluding to.

If I make gtk-update-icon-cache prerender svgs, it would certainly
prefer exisiting pngs of the same name, and only prerender to
"fill the gaps".

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

No very concrete plans yet, I just noticed that this is a (growing)
problem. If I do something about it,  it would probably require
passing an explicit argument to gtk-update-icon-cache, like

--prerender-sizes=16,24,32

so it should be harmless to add that  to the stable branch too.

Matthias