On Thursday 16 July 2009, Aaron J. Seigo wrote: > On Wednesday 15 July 2009, Marco Martin wrote: > > a way could be like now, parsing the key and throwing away other sizes of > > the same framesvg, or just revert that commit... > > i think the patch you attached will also kill other valid pixmaps to be > cached: two plasmoids with the same svg but rendered at different sizes == > only one gets cached == not good. > > sooo .. yes, that commit should probably just be reverted. unfortunate, as > it means more overhead per FrameSvg object which is something that is used > quite a lot. > > some per-caching-object accounting in Theme could help prevent this (and > others from falling into the same trap) but that's more work and similar > overhead (not to mention API changes)... > > +1 on reverting. ok, i'll revert (at least for 4.3), too bad because the code is way more clean now :( what would be better is theme::insertIntoCache(const QString& key, const QPixmap& pix, QObject *sender) but api change, big nono sigh :(
but a sick idea come to my mind: what about encoding the pointer value (or another random number, whatever) into the key? :p a key will have the form 7635865:path_300_200_blahblah in the cache only stuff after : will be saved as key, the first part (that can't be saved since wll change between sessions) just used to discard the useless ones :) _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
