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