Bug 110658 - Thumbnails generation process should have low priority
Summary: Thumbnails generation process should have low priority
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Thumbs-Engine (show other bugs)
Version: 0.7.3
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-12 21:45 UTC by Dik Takken
Modified: 2017-07-28 15:03 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.4.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dik Takken 2005-08-12 21:45:11 UTC
Version:           0.7.3 (using KDE KDE 3.4.1)
Installed from:    Gentoo Packages
OS:                Linux

When I open a album and start a OpenGL slideshow, the slideshow does not run smoothly because the thumb generation process consumes too many resources. The only solution seems waiting until all thumbs are generated before starting a slideshow.

Please lower the process priority of the thumbnail generation process.
Comment 1 krienke 2005-08-12 22:36:51 UTC
If low priority should be implemented it should be an option. I run my system (P4, 3GHZ) in dynamic mode i.e. the CPU speed is scaled down to keep the system silent if there is nothing to do. When there is nothing to do for the cpu it runs at a Speed of 1GHZ producing less heat than with 3GHZ and less noise. When there is something to do the system automatically scales up to the full speed of  3GHZ and down again if there is no active process. 

The problem is, that this scaling process to full speed happens only if the process is *not* running at a low nice level. So when thumb generation happens at a low nice level I would have the problem that the thumb generation is very very slow since it would be performed with 1GHZ speed instead of 3GHZ used now.

Comment 2 caulier.gilles 2006-08-30 12:28:29 UTC
SVN commit 578815 by cgilles:

digikam from trunk : When the Exif auto-rotation option is canged in setup dialog, digiKam ask now to user if the new batch tool to re-generate all albums items thumbnails must be started to refresh thumbs database.

CCBUGS: 127179, 110658, 128308

 M  +16 -0     setup.cpp  
 M  +25 -5     setupmetadata.cpp  
 M  +4 -1      setupmetadata.h  


--- trunk/extragear/graphics/digikam/utilities/setup/setup.cpp #578814:578815
@@ -30,11 +30,13 @@
 
 #include <klocale.h>
 #include <kiconloader.h>
+#include <kmessagebox.h>
 #include <kconfig.h>
 #include <kapplication.h>
 
 // Local includes.
 
+#include "batchthumbsgenerator.h"
 #include "setupgeneral.h"
 #include "setupmetadata.h"
 #include "setupidentity.h"
@@ -214,6 +216,20 @@
     d->slideshowPage->applySettings();    
     d->iccPage->applySettings();
     d->miscPage->applySettings();
+    
+    if (d->metadataPage->exifAutoRotateAsChanged())
+    {
+        QString msg = i18n("The Exif auto-rotate thumbnails option has been changed.\n"
+                           "Do you want to rebuild all albums items thumbnails now?\n\n"
+                           "Note: thumbnails processing can take a while!");
+        int result = KMessageBox::warningYesNo(this, msg);
+        if (result != KMessageBox::Yes)
+            return;
+
+        BatchThumbsGenerator *thumbsGenerator = new BatchThumbsGenerator(this);
+        thumbsGenerator->exec();
+    }
+
     close();
 }
 
--- trunk/extragear/graphics/digikam/utilities/setup/setupmetadata.cpp #578814:578815
@@ -58,6 +58,7 @@
 
     SetupMetadataPriv()
     {
+        ExifAutoRotateAsChanged   = false;
         saveCommentsBox           = 0;
         ExifRotateBox             = 0;
         ExifSetOrientationBox     = 0;
@@ -68,6 +69,9 @@
         saveCreditsIptcBox        = 0;
     }
 
+    bool       ExifAutoRotateAsChanged;
+    bool       ExifAutoRotateOrg;
+    
     QCheckBox *saveCommentsBox;
     QCheckBox *ExifRotateBox;
     QCheckBox *ExifSetOrientationBox;
@@ -163,16 +167,18 @@
     
     mainLayout->addWidget(hbox);
     mainLayout->addStretch();
+    mainLayout->addWidget(this);
 
+    readSettings();
+    adjustSize();
+  
     // --------------------------------------------------------
 
     connect(exiv2LogoLabel, SIGNAL(leftClickedURL(const QString&)),
             this, SLOT(processExiv2URL(const QString&)));
 
-    readSettings();
-    adjustSize();
-  
-    mainLayout->addWidget(this);
+    connect(d->ExifRotateBox, SIGNAL(toggled(bool)),
+            this, SLOT(slotExifAutoRotateToggled(bool)));
 }
 
 SetupMetadata::~SetupMetadata()
@@ -207,7 +213,8 @@
     AlbumSettings* settings = AlbumSettings::instance();
     if (!settings) return;
 
-    d->ExifRotateBox->setChecked(settings->getExifRotate());
+    d->ExifAutoRotateOrg = settings->getExifRotate();
+    d->ExifRotateBox->setChecked(d->ExifAutoRotateOrg);
     d->ExifSetOrientationBox->setChecked(settings->getExifSetOrientation());
     d->saveCommentsBox->setChecked(settings->getSaveComments());
     d->saveDateTimeBox->setChecked(settings->getSaveDateTime());
@@ -217,6 +224,19 @@
     d->saveCreditsIptcBox->setChecked(settings->getSaveIptcCredits());
 }
 
+bool SetupMetadata::exifAutoRotateAsChanged()
+{
+    return d->ExifAutoRotateAsChanged;
+}
+
+void SetupMetadata::slotExifAutoRotateToggled(bool b)
+{
+    if ( b != d->ExifAutoRotateOrg)
+        d->ExifAutoRotateAsChanged = true;
+    else
+        d->ExifAutoRotateAsChanged = false;
+}
+
 }  // namespace Digikam
 
 #include "setupmetadata.moc"
--- trunk/extragear/graphics/digikam/utilities/setup/setupmetadata.h #578814:578815
@@ -43,13 +43,16 @@
 
     void applySettings();
 
+    bool exifAutoRotateAsChanged();
+
 private:
 
     void readSettings();
 
 private slots:
 
-    void processExiv2URL(const QString& url);
+    void processExiv2URL(const QString&);
+    void slotExifAutoRotateToggled(bool);
 
 private:
 
Comment 3 Andi Clemens 2008-12-04 20:37:45 UTC
What about this report? Still valid? For me it runs smooth, but of course my hardware is newer then the one of the creation date of the bugreport :-)
Comment 4 caulier.gilles 2008-12-04 21:12:15 UTC
Same for me. Also, in KDE4, we use multithreading, not a kio-slave for previewing.

In all case, we will be able to adjust thread priority if necessary. 

Marcel, 

What do you mean to add a new settings for preview thread priority (like in Gwenview, if i'm not too wrong)

Gilles Caulier
Comment 5 caulier.gilles 2009-05-24 21:32:06 UTC
Marcel,

What do you think to use QThread::setPriority()

http://doc.trolltech.com/4.5/qthread.html#setPriority

with LoadSaveThread:

http://lxr.kde.org/source/extragear/graphics/digikam/libs/threadimageio/loadsavethread.h#66

Gilles Caulier
Comment 6 Marcel Wiesweg 2009-05-24 23:14:15 UTC
Yes this is always an option, if we want.
If we are creating thumbnails with the batch tools we can use this of course.
For the thumbnail loading thread for the main icon view, thumbbars or album sidebars we should not decrease priority because loading thumbnails there is directly needed by the user.
Comment 7 caulier.gilles 2012-01-25 13:49:35 UTC
*** Bug 291436 has been marked as a duplicate of this bug. ***
Comment 8 wuselwu 2012-01-25 17:29:30 UTC
Well, this bug is almost seven years old ;).
Comment 9 caulier.gilles 2014-09-08 12:43:03 UTC
Since multi-core computers are available everywhere, and as we have a maintenance tool dedicated to recompute all thumbnails, this entry do not have a sense for me.

In others words, thumbnails processing do not block GUI anymore using current implementation from git/master...

Gilles Caulier