Caching icon theme information

[Frans Englich]

On Wednesday 13 October 2004 20:17, Matthias Clasen wrote:
> Back in May, Owen Taylor proposed [1] caching scheme for icon theme
> information, to reduce the amount of stating and disk seeking at
> application startup, and to reduce the memory overhead if each app
> allocates all the icon theme data separately.
>
> The proposal is to keep the information about the icons in the
> directory tree below each icon theme directory in an mmap()able
> cache file (There is basically one cache file per index.theme file).
>
> The cache doesn't try to hold all information from the index.theme files
> that you would need to do lookups; it turns out that with the icon theme
> specification, this isn't even sensible - you can install a
>
>  $HOME/.local/share/icons/Bluecurve/index.theme
>
> That overrides
>
>  /usr/share/icons/Bluecurve/index.theme
>
> and chances how lookup happens for icons in /usr/share/icons/Bluecurve.
>
> We would like to propose the cache file format as an appendix to the
> icon theme specification. One thing which still needs to be investigated
> is caching of the actual image data; the file format is has an
> IMAGE_DATA_OFFSET member to allow adding that compatibly. An
> implementation of the caching scheme for GTK+ can be found at [2]. The
> cache generator which is included in the patch depends only on glib, and
> it may be a good idea to move it to freedesktop.org as well.
>
>
> Regards, Matthias Clasen
>
>
> The cache file format:
>
> Header:
> 2		CARD16		MAJOR_VERSION	1
> 2		CARD16		MINOR_VERSION	0
> 4		CARD32		HASH_OFFSET
> 4		CARD32		DIRECTORY_LIST_OFFSET
>
> DirectoryList:
> 4 		CARD32		N_DIRECTORIES
> 4*N_DIRECTORIES	CARD32		DIRECTORY_OFFSET
>
> Hash:
> 4		CARD32		N_BUCKETS
> 4*N_BUCKETS	CARD32		ICON_OFFSET
>
> Icon:
> 4		CARD32		CHAIN_OFFSET
> 4		CARD32		NAME_OFFSET
> 4		CARD32		IMAGE_LIST_OFFSET
>
> ImageList:
> 4		CARD32		N_IMAGES
> 4*N_IMAGES	Image		IMAGES
> Image:
> 2		CARD16		DIRECTORY_INDEX
> 2		ICON_FLAGS	FLAGS
> 4		CARD32		IMAGE_DATA_OFFSET
>
> ICON_FLAGS
> HAS_SUFFIX_PNG	1
> HAS_SUFFIX_XPM	2
> HAS_SUFFIX_SVG	4
> HAS_ICON_FILE	8
>

Such a cache would allow theme creators to maintain only an SVG set, and then 
have a tool which generates PNG version which then are embedded into the 
cache file(assuming the image caching is implemented).

In the "Icon theme specification: Standardizing icon names"[1] thread it is 
evident that an "pseudo icon" mechanism is necessary, a method which allows 
icon theme creators to say "this icon is also icon Foo, and icon Bar" -- 
without copying/duplicating images or using symlinks. The standardized names 
more or less relies on such a mechanism; many names allows flexibility, while 
creators still have the possibility to cover those names with a smaller set 
of actual images. Depending on how it's implemented, it also allows the 
creation of high performing icon themes(embedded devices etc).

My idea of specification is that the icon data file has an IsAlso field which 
is a semi colon separated string with the icon names it covers. For example, 
the icon data file for icon "navigator-reload" could have 
"IsAlso=system-reboot;document-reload;" and lookups on system-reboot would 
load the navigator-reload icon, for instance.

However, that IsAlso directive doesn't allow it to be done in a efficient and 
quick way. Perhaps this can be done with the cache? Like this:

Add a '4 CARD32 REAL_ICON_OFFSET' to Icon, which is the offset to the real 
Icon. If set to zero, the icon is not a pseudo icon. 

Implications(AFAICT):

* The file size increases with 4*<number of icons>. 

* IMAGE_LIST_OFFSET wouldn't make sense for pseudo icons then, and it should 
be zeroed. 

* It would complicate the cache generator.

* Converting to the standardized icon names once it's in the spec, will more 
or less require support for the IsAlso directive, and hence the cache(or 
doing it in some other way).

What is Icon::CHAIN_OFFSET btw? 


Yes, someone else should do the talking -- correct me.


Cheers,

	Frans

1.
http://freedesktop.org/pipermail/xdg/2004-October/005084.html