[Bug 166564] New: Display of *already* *created* thumbnails is slow

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         
           Summary: Display of *already* *created* thumbnails is slow
           Product: digikam
           Version: unspecified
          Platform: unspecified
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: kde-2 dotancohen com


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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From kde-2 dotancohen com  2008-07-14 20:28 -------
Created an attachment (id=26119)
 --> (http://bugs.kde.org/attachment.cgi?id=26119&action=view)
Screenshot illustrating problem. Note that all images have already been
thumbnailed. This is just waiting for the thumbnails to load.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         
andi.clemens gmx net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |0.10.0-svn
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From mikmach wp pl  2008-07-14 23:01 -------
Confirming this. Loading of thumbs for 0.10svn is terribly slow.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         
caulier.gilles gmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Thumbnails
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From marcel.wiesweg gmx de  2008-07-17 21:49 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From marcel.wiesweg gmx de  2008-07-17 21:49 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From marcel.wiesweg gmx de  2008-07-17 21:50 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From marcel.wiesweg gmx de  2008-07-17 22:20 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Jasper]

Bugzilla from [e-mail] wrote

     
http://bugs.kde.org/show_bug.cgi?id=166564         

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.

 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?

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From marcel.wiesweg gmx de  2008-07-19 15:45 -------
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?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From marcel.wiesweg gmx de  2008-07-19 15:55 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From mikmach wp pl  2008-07-19 21:48 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From caulier.gilles gmail com  2008-07-19 23:05 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From kde-2 dotancohen com  2008-07-20 09:41 -------
> 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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From mikmach wp pl  2008-07-20 12:55 -------
Gilles, testing collection is small comparing to main collection,
testing albums are ca 300-600 images and it is working fine.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Jasper]

Bugzilla from [e-mail] wrote

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.

Can we do this in the source in the meantime? Q=how

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         
mikmach wp pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From mikmach wp pl  2008-07-22 15:56 -------
There may be some issues like configuration of RAM  but main scope of this bug  is fixed.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=166564         




------- Additional Comments From marcel.wiesweg gmx de  2008-07-26 22:28 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel