[Digikam-devel] Introduction and comments about bug:137320

[Arnd Baecker]

Hi Pau,

On Wed, 5 Mar 2008, Gilles Caulier wrote:

> 2008/3/5, Pau Rul·lan Ferragut <paurullan at bulma.net>:

[...]
>> I have used digikam for a long time and I decided to start contributing 
>> to the project.
>
> Thanks to contribute...

Yes, contributions are indeed very welcome!!

> Please read this page before (just to be sure) :
> http://www.digikam.org/?q=contrib
>
> ...especially "Submitting patches" section.
>
>
> The first thing I would like to do is to get rid of the stoping
>> thumbnail bug:
>> http://bugs.kde.org/show_bug.cgi?id=137320
>>
>> Do any of the core developers believe this is too dificult to begin or are
>> working on it?
>
> Me and Marcel we work on KDE4 port.
>
> I know than Arnd said to me by IRC than he will be interested to fix this
> problem too.

Yes, it is an annoying one ;-), but so far I did not have any time
to look into this, so, Pau, your contribution would be very much
appreciated!

> But I am having a dificult time trying to understand the scheme of the
>> program. Which modules are involved in the process?
>
> It's not to difficult, but code to touch is indeep in core implementation
> from digikam/digikam subfolder. Look here :
>
> - a class named PixmapManager handle thumbs image for each icon item.
> - a class named AlbumIconView manage view of icon from main interface.
>
> in AlbumIconView, we have a method named nextItemToThumbnail() which is
> called by PixmapManager::slotComplete() when a thumb have been found in
> cache (or regenerate in background if necessary by a kio-slave)
>
> When you select a new album or if you scrool icon view, PixmapManager will
> call AlbumIconView::nextItemToThumbnail() to get the next icon instance to
> thumbnailize.
>
> Now if you look how AlbumIconView::nextItemToThumbnail() method work, you
> will see than the first and the last _visible_ items are used to limit
> regeneration of thumbs...
>
> If you want to change the behaviours of thumbnails genration done in
> background the code from AlbumIconView::nextItemToThumbnail() need to be
> fixed to handle the first and the last iconview item item from current
> album, not the visible ones.
>
> But take a care : regenerate all icon thumbs in background take a while,
> especially with slow computer. Of course a kioslave is a separate process
> which run outside of digiKam but we don't have any control to set the
> priority (as a separate thread)
>
> So, for huge album and slow computer (using a single processor especially)
> thumb generation will slow down digiKam. This is why the current thumbs
> generation behaviours have been implemented to only generate current visible
> items.

Just a comment on the possible performance:
What happens, if one displays a huge album (e.g. all images from 2007),
where the thumbnails have not been generated?
Possible problems:
- moving to a different place (with the slider) in the same view:
   would those images thumbnails only be displayed after all other ones
   have been generated?
   (Or are thumbnails for images currently in view generated first?)
- if one then moves to a different view (e.g. 2006),
   will the 2007 thumbnails be still generated in the background?
   (I.e., is there any way to stop the thumbnail generation when
    changing views, so that full priority goes to the currently wanted
    thumbnails?)

> This is my proposal :
>
> - added a new option in "Album Settings" page from Setup dialog, into
> "Interface Options". A checkbox is enough here. The new option must be
> disable by default.

Yes, something like: "[ ] Load all thumbnails of the current view"

> - patch AlbumSettings class to manage this new option.
> - patch AlbumIconView::nextItemToThumbnail() to handle this option (thrue an
> AlbumSettings method) to change behaviours accordingly (only visible items
> or all items)

Of course, for a start (to try out that feature), one
could just change AlbumIconView::nextItemToThumbnail()
and see how it performs. Maybe some (user-definable) limitation
(like 20 images etc.) is needed.

Best, Arnd