Projects/Summer of Code/2007/Projects/Icon Cache

From KDE TechBase
Revision as of 15:41, 30 May 2007 by Rivol (talk | contribs) (add soc iconcache page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

KDE Icon Cache

Author

Name: Rivo Laks

Mentor is Aaron Seigo

Abstract

To improve startup times of KDE applications, I plan to create an icon cache which would store all icons in a common location. This would eliminate the need to scan tens of directories for icon locations, thus reducing disk seeking. And as the cache would consist of only two files, it would often be wholly cached in the memory by the operating system, eliminating disk access completely. Furthermore, the cache enables loading icons directly from SVGs, using any scale, as the SVGs need to be converted into pixmaps only on the first use. Finally, the cache would make it possible to support simple icon compositing, making it much easier for third-party applications to provide icons which always fit into user's current icon theme.


Code

Code will be available from KDE's SVN server, under /branches/work/soc-iconcache


Implementation

The icon cache will consist of two files: one will be index and the other will hold the actual data.

The index file will hold pairs of keys and offsets where key is md5 or similar hash of the requested data (e.g. "<icon name> <size> ...") and offset is offset of the data associated with this key in the data file. Index will probably be implemented using either AVL- or B-tree.

The data file will consist of icon datas, written one after another. One such data would contain name of the icon, last used timestamp, it's size, applied effects (e.g. greyscale) and of course the pixmap data itself (probably in a compressed format).

To keep the cache's size within reasonable limits, a daemon similar to kio_http_cache_cleaner would periodically check it's size. If the cache is too big, the daemon would rebuild it from scratch, inserting 80% or so of the most recently used entries. This would avoid having to support on-the-fly deletion of entries and thus make the cache faster.