Bug 92017 - Huge performance impact of EXIF based thumbnail rotation
Summary: Huge performance impact of EXIF based thumbnail rotation
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Orientation (show other bugs)
Version: 0.7.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-24 18:06 UTC by Marcel Wiesweg
Modified: 2022-01-19 10:56 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 7.6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Wiesweg 2004-10-24 18:06:44 UTC
Version:           0.7-beta1 (using KDE 3.3.1, SuSE)
Compiler:          gcc version 3.3.1 (SuSE Linux)
OS:                Linux (i686) release 2.6.6

When using digikam on a large album (1700 photos) I noticed a massive event loop impact which means very sluggish GUI responsiveness. I did some investigation with gettimeofday()-measurements.

I measured the performance of AlbumIconView::slotGotThumbnail which is obviously called 1700 times in my test case.

Average time taken with EXIF based rotation turned on:
37000 microseconds
and with EXIF turned off:
26 microseconds.

The reason is obvious, you rotate every picture be it actually displayed or not. (and there are only 9 pictures displayed with large thumbnails)
The time spent in this function alone (not for loading the thumbnail!) amounts to 60 seconds on my machine, all in the event loop.
Comment 1 Renchi Raju 2004-10-24 20:51:56 UTC
CVS commit by pahlibar: 


* implemented a native exif orientation reading function based on the exif
  orientation writing one in libkexif. this will be moved to libkexif 
  in v0.2
* performance comparisons for reading exif orientation of 609 jpeg files:
  total time (for libexif based implementation) : 163304 microseconds
  total time (for native implementation)        :   9925 microseconds

i'm not closing the bug now. please try this out and see if it gives you
acceptable results
CCBUG: 92017


  A            exiforientation_p.h   1.1 [GPL]
  M +12 -5     albumiconview.cpp   1.90
  M +1 -1      albumiconview.h   1.28


--- kdeextragear-3/digikam/digikam/albumiconview.cpp  #1.89:1.90
@@ -102,4 +102,5 @@
 #include "cameradragobject.h"
 #include "dragobjects.h"
+#include "exiforientation_p.h"
 
 #include "albumiconitem.h"
@@ -1691,14 +1692,22 @@ void AlbumIconView::slotSetExifOrientati
 }
 
-void AlbumIconView::exifRotate(QString filename, QPixmap& pixmap)
+void AlbumIconView::exifRotate(const QString& filePath, QPixmap& pixmap)
 {
    // Rotate thumbnail based on EXIF rotate tag
     QWMatrix matrix;
 
-    KExifData *exifData = new KExifData;
+    /*
+    KExifData exifData;
 
-    if(!exifData->readFromFile(filename)) return;
+    if(!exifData.readFromFile(filename))
+    {
+        return;
+    }
 
     KExifData::ImageOrientation orientation = exifData->getImageOrientation();
+    */
+
+    KExifData::ImageOrientation orientation
+        = getExifOrientation(filePath);
 
     bool doXform = (orientation != KExifData::NORMAL &&
@@ -1745,6 +1754,4 @@ void AlbumIconView::exifRotate(QString f
        pixmap = pixmap.xForm( matrix );
 
-    delete exifData;
-
 }
 

--- kdeextragear-3/digikam/digikam/albumiconview.h  #1.27:1.28
@@ -125,5 +125,5 @@ private:
     AlbumIconViewPrivate *d;
     
-    void           exifRotate(QString filename, QPixmap& pixmap);
+    void           exifRotate(const QString& filePath, QPixmap& pixmap);
     void           updateItemRectsPixmap();
     bool           showMetaInfo();


Comment 2 Renchi Raju 2004-10-24 21:53:29 UTC
CVS commit by pahlibar: 



* minor optimization: moved the exif rotation from albumiconview to 
  thumbnailjob and rotate the thumbnail qimage before converting
  to qpixmap. rotating the qimage is almost 5 times faster than 
  rotating a qpixmap.
* side effect of this is that everything using thumbnailjob gets
  exif oriented thumbnails for free, including the comments/tag
  editor
CCBUG: 92017


  M +2 -77     albumiconview.cpp   1.91
  M +0 -1      albumiconview.h   1.29
  M +0 -1      imagedescedit.cpp   1.23
  M +60 -0     thumbnailjob.cpp   1.8
  M +1 -0      thumbnailjob.h   1.4



Comment 3 Marcel Wiesweg 2004-10-25 22:59:21 UTC
Thank you, now the difference is no longer subjectively noticeable.
Comment 4 Renchi Raju 2004-11-17 07:05:11 UTC
CVS commit by pahlibar: 



* all thumbnail loading/generating/exif-rotating/caching tasks have been
  offloaded to the digikamthumbnail kioslave. the main gui just does the
  task of converting the image supplied by the kioslave to qpixmap and
  painting it. This significantly boosts gui responsiveness
* instead of loading the cached thumbnail using qimage, a native png loader
  is loader with significant speed improvements in thumbnail loading 
  (approx 5x)
* the Digikam namespace has been dropped from ThumbnailJob class, as it was
  a remnant of the 0.6.x series

* please test for any regressions
* the gdbm preload thumbnail hack has been temporarily turned off. the new 
  thumbnail loading speed is much improved and user tests are requested to
  see if still need to retain this hack
* TODO: design a proper caching mechanism for pixmaps, so that only a certain
  number of them are retained in memory

BUG: 92017


  A            kioslave/exiforientation_p.h   1.1 [GPL]
  M +3 -3      digikam/albumfolderview.cpp   1.62
  M +1 -5      digikam/albumfolderview.h   1.21
  M +5 -5      digikam/albumiconview.cpp   1.97
  M +1 -1      digikam/imagedescedit.cpp   1.27
  M +1 -1      digikam/imagedescedit.h   1.11
  M +3 -3      digikam/syncjob.cpp   1.10
  M +24 -285   digikam/thumbnailjob.cpp   1.11
  M +1 -12     digikam/thumbnailjob.h   1.7
  M +3 -2      kioslave/Makefile.am   1.10
  M +287 -43   kioslave/digikamthumbnail.cpp   1.9
  M +5 -1      kioslave/digikamthumbnail.h   1.3
  R            digikam/exiforientation_p.h   1.2



Comment 5 Mikolaj Machowski 2004-11-17 23:57:09 UTC
> * the gdbm preload thumbnail hack has been temporarily turned off. the
> new thumbnail loading speed is much improved and user tests are
> requested to see if still need to retain this hack

Are you sure it was turned off? My today's version from CVS still was
going from pixelized images to full version. Only after I moved
.thumbnails/digikam-thumbnails.db it wasn't used.

I have mixed feelings. Difference in speed between _previous_ (with gdbm
hack) version of loading thumbnails and current loading - counting up to
full view of album isn't noticeable. But: current version of algorithms
AND gdbm 'hack' is much faster. And nicer to view.