Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8

[Alan Cox <alan lxorguk ukuu org uk>]

On Gwe, 2004-06-25 at 00:54, Mike Hearn wrote:
> 3) Introduce a new icon theme format and ship themes packed - that
> requires you to have an up to date desktop otherwise some themes will
> just mysteriously not work, and is equivalent to scrapping the current
> spec. Not Good. Inventing specs then abandoning them months later is
> arguably the same as breaking backwards compatibility in that spec.

I would say introduce the new icon theme format as an optimisation for
2.7->2.8. Keep support for the old format and also mapping tools. That
means you can either

a) pack a theme and take the disk hit
b) pack the theme and flush the original
c) leave it as is

I'd suspect vendors would ship standard themes in format (b),
most themes would come out in format (c) and people who cared about
performance would do (a) or (b) themselves. In fact themes should come
out in the current format because you can't edit the packed one
without unpacking and repacking.

To me its a cache format. If bluecurve.pac present use it if not load
them up. Hell you could make the first client generate the pac file if
there wasn't one.

> 4) Just cache the icon metadata then mmap each icon in use separately.
> Sizes for 32x32 icons seem to always be <4k, largest size of 192x192
> tends to be ~20k. SVG icons seem to be quite small (<4k) too. I have no

The moment its not one file you lost the speed up on init. IDE disk
throughput versus seek really is that dramatic. We've got from
2Mbyte/second 8mS seek to 40Mbyte/sec 4.5mS seek. What costs at start up
is the seeks and opens - same for gconf alas.

I've been doing a bit more work on it - I've added a hash table so that
you can pack an entire theme without taking too much of a hit on search
though the index. The hash is also shared/platform independant so isnt
per user, and the hashing and sorting is done by the packer so it has no
load time impact at all.