| Summary: | Display of *already* *created* thumbnails is slow | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Dotan Cohen <kde-2011.08> |
| Component: | Thumbs-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 0.10.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Screenshot illustrating problem. Note that all images have already been thumbnailed. This is just waiting for the thumbnails to load. | ||
|
Description
Dotan Cohen
2008-07-14 20:26:16 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.
Confirming this. Loading of thumbs for 0.10svn is terribly slow. 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 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 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 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. 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? 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. 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. 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 > 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.
Gilles, testing collection is small comparing to main collection, testing albums are ca 300-600 images and it is working fine. There may be some issues like configuration of RAM but main scope of this bug is fixed. 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 The KPhotoAlbum has an idea: http://www.kdedevelopers.org/node/4295 Thumbnails in digikam are stored in a database. So this doesn't help much. |