[Digikam-devel] [Bug 166564] Display of *already* *created* thumbnails is slow

[Jasper Aorangi]

Bugzilla from marcel.wiesweg at gmx.de 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?
-- 
View this message in context: http://www.nabble.com/-Bug-166564--New%3A-Display-of-*already*-*created*-thumbnails-is-slow-tp18450027p18525633.html
Sent from the digikam-devel mailing list archive at Nabble.com.