Bug 92017

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();

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

Thank you, now the difference is no longer subjectively noticeable.

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

> * 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.