As the title says, I've finally merged my Summer of Code project - icon and pixmap cache - into kdelibs.
Buildsystem changes are not done yet, I'll do them in the next days. Until then, you might see old icons after new ones are installed. If you really need the new ones, do touch -m $KDEDIR/share/icons/hicolor/. Then the cache will notice the new icons.
The pixmap cache is meant to make disk caching of e.g. pixmaps rendered from SVGs very easy for app developers. It's API is similar to that of the QPixmapCache and I'm planning to create a TechBase tutorial soon to make it's adoption even easier.
Subscribe to:
Post Comments (Atom)
8 comments:
Congrats, mate!
Are you trying to keep icons placed close by they use?
Some icons are known to be used in sequence, and if you can stick them in the same page, or sequential pages, then we'll be benefited by system's read ahead and other prefetch mechs.
Federico's blog, from Gnome fame, have some work on this and achieved benefits. Better not stay too far behind on this area too.
ivan: thanks :-)
gustavo: it will be possible to optimize the cache that way, but it probably won't make it into 4.0. BTW, the idea is to have the entire cache preloaded into memory anyway.
Congratulations on your excellent work. :)
is this going to also boot performance a bit?
merlin: sure, that's one of it's benefits.
Little advertising: you can find out more about the cache in tomorrow's KDE Commit Digest ;-)
Hi,
I just took a look at the API, and it looks nice, just one thing:
In the KPixmapCache::find method, you use a reference to update the object. Any reasons not to make it a pointer such as mentioned in http://doc.trolltech.com/qq/qq13-apis.html#pointersorreferences
It does make reading the code easier (at least for people like me, who conditioned themselfes this way :-)
One annoying thing about pointers parameters is that they always have the nagging question associated with them of how is NULL handled. As a result, I personally, like to reserve them only for when NULL has special valid semantics (e.g., specifies using the defaults for a paramater).
Nonetheless, that is an interesting point that QT makes. Not sure that it out weights the other though as, if you are using pointers throughout your code, it will be very infrequent that you use & with function parameters anyway (i.e., mostly you will just be passing along pointers).
Post a Comment