anyone looking for an interesting kde4 programming problem to tackle? well, i just might have something for you.
we now have a set of high quality svg icons sitting all pretty like in kdelibs with the oxygen theme. unfortunately, svg is not as fast to render as, say, blitting a pixmap to screen is (duh!). zack's done amazing work, but svg is still svg. =)
which leads us to the following problem:
how do we use svg and get perfectly scalable icons without sacrificing speed? in fact, could we even get better speed? i think we can. how? by having the icon loader render the svg's on demand into a shared, on-disk binary cache. in fact, such a cache could even be generated at installation time for the default icons.
well, first the obvious: we get to use svg at arbitrary sizes with the speed of blitting pixmaps minus a one-time rendering fee.
the almost-as-obvious: by putting icons into a single file, application start up should get faster as we will only need to do the "seek to a million locations on disk per icon" for that one-time rendering. ok, it's not a million locations, but it can still easily be a dozen or so. and since moving physical parts == slow, this should result in a speed up. in fact, talking with someone some months ago who had experimented with caching even just the current png's into a single cache file that is loaded on app startup showed user noticeable start up improvements. note that this is different than suggesting an icon server.
the perhaps not-so-obvious: this would open the door to doing run-time composition of icons. e.g. we can make it so the icon theme can be queried for "mimetype for foo" and if there is no mimetype-foo icon, but there is a foo icon, then it could take the generic mimetype icon, draw the foo icon into it ("into" is key; there's probably need for under- and over-lay to get things looking properly). the beauty of this is that apps can then stop shipping their owm mime type icons which look out of place, or which look good today but end up looking like crap later when the base icon theme changes. and that's just one example. while tagging he icons in crystalsvg as research for the oxygen artists, it became apparent that most of our icons are simply composites of standard elements with zero or one custom elements added in. while we certainly won't be able to provide all icons that are composites of more basic elements, we can get a lot closer to dynamic icons than we are at now.
the down side is that it will result in more per-user disk space. so this probably needs to be configurable in the loader, though with disk as cheap as it is the tradeoff should be well worth it.
it's also not completely trivial: to really be effective, it needs to be fault tolerant (e.g. detect cache corruption; having messed up icons isn't an option =), multi-reader, multi-writer and random-access efficient. it needs to be indexed for fast look ups, etc. the usual, really. so there's almost certainly existing libraries that can be used for this.
of course, i could be completely, totally wrong and this could end up being little or no better than straight up old-school icon loading as we currently do it. so there is a bit of risk involved, but i'm guessing the speed boost will be real and noticeable. assuming our runtime svg rendering is good enough, we should see improvements in icon presentation, particularly when we aren't using one of the "standard" sizes. this neatly gets around the problem of not having 24 pixel icons in a lot of themes, for instance.
if nobody steps up to do this, i'll eventually get to it someday. but i'm completely stuffed for 4.0 at this point. however, i'm happy to help mentor someone through the requirements and it would make a positively awesome SoC project. *hint* =)