Bug 166564 - Display of *already* *created* thumbnails is slow
Summary: Display of *already* *created* thumbnails is slow
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Thumbs-Image (show other bugs)
Version: 0.10.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-14 20:26 UTC by Dotan Cohen
Modified: 2010-08-02 22:14 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot illustrating problem. Note that all images have already been thumbnailed. This is just waiting for the thumbnails to load. (266.37 KB, image/png)
2008-07-14 20:28 UTC, Dotan Cohen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2008-07-14 20:26:16 UTC
Version:           SVN: Version 0.10.0-beta2 (rev.: 832007) (using KDE 4.0.83)

There are many bug reports asking for thumbnails to be generated during X condition for Y purpose. This is not a dupe of one of those :)

Although Digikam is understandably slow to produce and show thumbnails for images that have yet to be thumbnailed, Digikam is also a bit slow to show the thumbnails that have already been generated. Directly after running "rebuild all thumbnails" I can switch to a new album and Digikam takes a full second to fill up the screen with thumbnails. This is on a 2.0Ghz dual core system with 2 GB ram and only Firefox (with 3 very lightweight extensions) running in the background.
Comment 1 Dotan Cohen 2008-07-14 20:28:14 UTC
Created attachment 26119 [details]
Screenshot illustrating problem. Note that all images have already been thumbnailed. This is just waiting for the thumbnails to load.
Comment 2 Mikolaj Machowski 2008-07-14 23:01:04 UTC
Confirming this. Loading of thumbs for 0.10svn is terribly slow.
Comment 3 Marcel Wiesweg 2008-07-17 21:49:47 UTC
SVN commit 834003 by mwiesweg:

Use update, not repaint. Avoids a repaint cycle synchronous after

each delivered thumbnail.

CCBUG: 166564


 M  +1 -1      albumiconview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=834003
Comment 4 Marcel Wiesweg 2008-07-17 21:49:49 UTC
SVN commit 834004 by mwiesweg:

Install a shortcut to rule out that inter-thread signalling can become

a limiting factor for thumbnail loading performance

CCBUG: 166564


 M  +58 -4     thumbnailloadthread.cpp  
 M  +10 -0     thumbnailloadthread.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=834004
Comment 5 Marcel Wiesweg 2008-07-17 21:50:24 UTC
SVN commit 834008 by mwiesweg:

Make use of the prepareRepaint method (called before each repaint)

to restore the good old behavior that thumbnail are loaded top-to-bottom
(by prepending the whole group as one)

CCBUG: 166564


 M  +11 -0     albumiconview.cpp  
 M  +2 -0      albumiconview.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=834008
Comment 6 Marcel Wiesweg 2008-07-17 22:20:28 UTC
Please test if the changes above improve the situation.

To have valid tests, please remove the influence of hard disk access - use a large album (a few hundred images), scroll slowly to the bottom so that all thumbnails have once been loaded and are in Linux' disk cache. Then go up again to images that have fallen out of (our pixmap) cache.

With Callgrind, in this loading situation, 70% is spent inside libpng. Note that the code for loading pregenerated thumbnails with libpng did not change since KDE3. 8% in QImage::scaled, 20% in the event loop. This misses all time spent in X11, so drawing is the one area that may be a problem currently - and drawing speed, graphics driver problems may enter the scene here.
Comment 7 Marcel Wiesweg 2008-07-19 15:45:14 UTC
Importing a mail from Jasper Aorangi:

 Please excuse if this is off topic,
just browsing albums showed a great improvement in speed of thumbnails
loading. Previously thumbnail loading on scrolling was very slow, and
thumbnails seemed to be reloaded once out of view by a page and a half, with
some becoming grey etc. Unfortunatley this greying out of thumbnails is
still happening  to the images at the beggining of the album having scrolled
to the bottom. 
 As a comparison to gqview, which takes a while to load thumbnails granted,
once loaded there is no lag in scrolling or displaying thumbnails even with
*very* large albums and scrolling quickly. THere is no 'redraw' effect
evident. 
This is the behaviour I expect with digikim. Is this a false expectation.
 On a similar note, can digikam be set to load all thumbnails in an album,
rather than wait for the thumbnail to come into view then load them?
Comment 8 Marcel Wiesweg 2008-07-19 15:55:23 UTC
Currently only 100 thumbnails are cached. I will look into changing this limit to be based on memory usage (pixmaps are stored by the X server, but they take memory nonetheless. A maximum size thumbnail (256px) takes 16 times more memory than a small thumbnail with size 64). To adjust the maximum limit, we thought of providing a slider for globally adjusting cache sizes in digikam. If you have a machine with 4GB RAM you easily spend a few MBs more for thumbnail caching than e.g. I do with my 512MB laptop.

The bahavior of greyed out thumbnails is unclear to me. Before first loading, the area is painted white. Before further reloads, it is grey. I need to investigate this.
Comment 9 Mikolaj Machowski 2008-07-19 21:48:40 UTC
This fixed for me. Now thumbnails load really fast. IMO faster than in
0.9.x series. Note that size of my collection for 0.10 is much smaller
- don't know if this is of any significance.
Comment 10 caulier.gilles 2008-07-19 23:05:21 UTC
Mik,

Like Marcel said, the thumbs cache is limited to 100 items. So, album contents size is very important. Try to make an album with 200 or 300 items for ex. 

Note: it's easy to do to use album recursive mode for example, with a huge album hierarchy, each one including a lots of items.

Gilles Caulier
Comment 11 Dotan Cohen 2008-07-20 09:41:18 UTC
> Like Marcel said, the thumbs cache is limited to
> 100 items. So, album contents size is very important.
> Try to make an album with 200 or 300 items for ex.

Can this be configurable? Our desktop machine is _mostly_ used just for organizing pictures, and it currently has 1GB of RAM that would otherwise be going to waste. The motherboard supports up to 4GB RAM and I'd happily max it out if Digikam would support it.
Comment 12 Mikolaj Machowski 2008-07-20 12:55:57 UTC
Gilles, testing collection is small comparing to main collection,
testing albums are ca 300-600 images and it is working fine.
Comment 13 Mikolaj Machowski 2008-07-22 15:56:42 UTC
There may be some issues like configuration of RAM  but main scope of this bug  is fixed.
Comment 14 Marcel Wiesweg 2008-07-26 22:28:50 UTC
SVN commit 838128 by mwiesweg:

Calculate cache cost of thumbnail cache based on used memory, not simply

the number of cached thumbnails. This means for thumbnails of size 64
there will be 16 times more (*) thumbnails cached than for size 256.

(*) For QPixmaps, memory usage is not directly accessible. I use size and depth
and calculate the max cost based on the display's default depth.

CCBUG: 166564


 M  +6 -4      loadingcache.cpp  
 M  +6 -2      loadingcache.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=838128
Comment 15 Dotan Cohen 2010-08-02 22:08:48 UTC
The KPhotoAlbum has an idea:
http://www.kdedevelopers.org/node/4295
Comment 16 Johannes Wienke 2010-08-02 22:14:46 UTC
Thumbnails in digikam are stored in a database. So this doesn't help much.