Bug 291436 - Optimize thumbnail generation process - is painfully slow in certain usage cases
Summary: Optimize thumbnail generation process - is painfully slow in certain usage cases
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Thumbs-Engine (show other bugs)
Version: 2.4.1
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-13 12:35 UTC by wuselwu
Modified: 2019-08-15 15:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 6.3.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wuselwu 2012-01-13 12:35:23 UTC
Version:           2.4.1 (using KDE 4.7.4) 
OS:                Linux

I'd propose that the way Digikam creates thumbnails is overhauled (easy to demand that, probably difficult to implement, I know).

When dealing with many pictures and with bigger filesizes (as are customary nowadays also for customer digital cameras), the thumbnail generation and especially regeneration is getting painfully slow. E.g. if doing some batch geotagging or renaming of the photos - nothing of which should require a recreation of the thumbnails - Digikam can get unusable for minutes. In some cases I even have to restart Digikam because the thumbnail generation seems to be in an endless loop.

I don't know how Digikam decides that it has to recalculate its thumbnails. In my perception, however, there does not seem to be an intelligent algorithm behind that. If anything is changed, everything is rebuilt, and in the case of bigger or more pictures, Digikam sometime chokes on the workload.

Moreover, there is apparently no multithreading going on.

Reproducible: Always



Expected Results:  
Only thumbnails with changed picture content should be rebuilt.
Comment 1 caulier.gilles 2012-01-25 13:49:35 UTC

*** This bug has been marked as a duplicate of bug 110658 ***
Comment 2 caulier.gilles 2019-08-15 15:21:10 UTC
Fixed with bug #110658