Bug 117301 - Thumbnails generation process running for visible thumbnails only, if it is sensible in order to avoid unnecessary waiting.
Summary: Thumbnails generation process running for visible thumbnails only, if it is s...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Thumbs-Engine (show other bugs)
Version: 0.8.2
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-29 21:57 UTC by S. Burmeister
Modified: 2017-07-28 15:03 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description S. Burmeister 2005-11-29 21:57:31 UTC
Version:            (using KDE KDE 3.5.0)
OS:                Linux

Since 0.8 thumbnails are only loaded, if they are displayed, no matter for how long the system was idle. As a result the user has to wait for the thumbnails every time s/he scrolls. The reason for this behaviour is to save memory.

However, waiting is quite annoying, so the behaviour described above should only be used when necessary and not if a folder only has ~50 pictures.

I am not sure what picture number is a good one, yet digikam should count the images before deciding whether it is necessary to save memory, or whether thumbnails for the current folder can be pre-loaded and thus improve user experience.
Comment 1 Tom Albers 2005-12-29 20:41:24 UTC
We did some testing when we implemented it and we decided that there was no need to do it, because the thumbs appear almost instantly, do you have any idea why that is not the case for you?
Comment 2 S. Burmeister 2005-12-31 11:52:14 UTC
I guess there are at least two factors:

1. Data to read, if there is no thumbnail in the file, the file has to be read, as megapixel-numbers increase, the file-size will get bigger and bigger, i.e. it will take more and more time to read and process.

2. CPU speed.
Comment 3 Sami Cokar 2006-12-13 04:14:57 UTC
I also experience this 'annoyance' on a Pentium IV 2.2GHz PC running Kubuntu Feisty (pre-release).  However, the default kernel currently has hard disk DMA/etc disabled.

I will let you know if performance improves during Feisty's release cycle.
Comment 4 Gilles Schintgen 2007-04-09 14:28:46 UTC
I agree that thumbnail loading while scrolling is almost instantaneous. Yet, the delay is still noticeable and that's a (very minor!) inconvenience. IMO digikam should do more aggressive thumbnail preloading. You could have a look at the similar options of kpdf (Settings / Performance / Memory usage) which I find quite useful. (E.g. low ressource usage for laptops vs. aggressive setting for workstations.)
Comment 5 Arnd Baecker 2007-09-05 08:32:22 UTC
For example pre-loading the next two rows might
already be sufficient to give a much smoother user experience ;-)

Note that this is also related (not the same!) to 
http://bugs.kde.org/show_bug.cgi?id=137320
and the bugs mentioned there.

Also note that there is a small bug about caching raw files in full preview
in the album view,
http://bugs.kde.org/show_bug.cgi?id=132047
Comment 6 caulier.gilles 2011-12-12 12:18:35 UTC
This entry still valid with 2.4.0 release ?

Gilles Caulier
Comment 7 caulier.gilles 2012-01-26 13:49:12 UTC
Marcel,

For me this old entry is fixed in current implementation from git/master. I cannot reproduce unnecessary waiting to load visible item thumbnails.

Fine to close ?

Gilles Caulier
Comment 8 Marcel Wiesweg 2012-01-26 21:03:52 UTC
Sure. Fixed for a looong time.