From kde-commits  Sat Sep 11 23:11:35 2010
From: Michael Pyne <mpyne () kde ! org>
Date: Sat, 11 Sep 2010 23:11:35 +0000
To: kde-commits
Subject: KDE/kdelibs/kdeui/icons
Message-Id: <20100911231136.04727AC888 () svn ! kde ! org>
X-MARC-Message: https://marc.info/?l=kde-commits&m=128424644123543

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;
         }
     }