[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    KDE/kdelibs/kdeui/icons
From:       Michael Pyne <mpyne () kde ! org>
Date:       2010-09-11 23:11:35
Message-ID: 20100911231136.04727AC888 () svn ! kde ! org
[Download RAW message or body]

SVN commit 1174319 by mpyne:

Ensure that pixmaps loaded by KIconLoader are cached in the process-local
pixmap cache.

Matthias Fuchs pointed out to me that loading the same icon a hojillion times
(well ok, a 1000) takes up a lot of time in simply reading the image data.
Which is weird, given that KIconLoader is supposed to cache the pixmaps as
well.

I confirmed the issue and it turns out that's because KIconLoader only adds
entries to the process-local pixmap cache at the same time it adds entries to
the process-shared image cache. So if Process A was the first one to add an
icon to the shared cache, Processes B, C, etc. would always re-read the shared
image data every time the icon was needed, and never cache the generated
pixmap.

If Process A then closed, no KDE process would cache the pixmaps until the icon
was ejected from the shared cache somehow.

This passes the kiconloader test cases, and is a possibility for backporting,
which I'll ask about separately. This commit affects KDE Platform 4.6.


 M  +7 -0      kiconloader.cpp  


--- trunk/KDE/kdelibs/kdeui/icons/kiconloader.cpp #1174318:1174319
@@ -885,6 +885,13 @@
             data = tempPixmap;
             path = tempPath;
 
+            // Since we're here we didn't have a QPixmap cache entry, add one now.
+            PixmapWithPath *newPixmapWithPath = new PixmapWithPath;
+            newPixmapWithPath->pixmap = data;
+            newPixmapWithPath->path = path;
+
+            mPixmapCache.insert(key, newPixmapWithPath, data.width() * data.height() + 1);
+
             return true;
         }
     }
[prev in list] [next in list] [prev in thread] [next in thread]