Bug 182743

I can not confirm this, works fine for test albums with over 2000 images...

Andi

Same here. It's work fine with my huge collections

Gilles

Hmm I must revoke my opinion, I now can confirm that opening a folder with 300 or more images will make "advanced slideshow" unresponsive for quite some time. I just tested it again.

Andi

*** Bug 194355 has been marked as a duplicate of this bug. ***

There are several problems with this plugin:

1. It will always load all images in the beginning. If you have an album open with 6000 images (for example a digiKam tag album), it will try to load all of them, even when a selection is made.
It is also much slower then in other plugins, I have not figured out why.
When I open 1900 images in RemoveRedEyes, it takes 5 seconds to load the image list.
But in AdvancedSlideshow, it takes over 4 minutes.

2. There seems to be no way to add only the selected images, and even when the dialog has been loaded, the "display only selected images" radiobutton is always grayed out.

3. When you finally managed to load the imageslist and start the slideshow, it takes, again, ages before the slideshow starts.

There might be performance issues from KIPI interface, but something is definitely also wrong in the plugin.

Gilles, as you know KIPI a little bit better, do you understand what is going wrong here?

The "slow part" can be found here:
http://lxr.kde.org/source/extragear/graphics/kipi-plugins/advancedslideshow/maindialog.cpp#537

There might be other parts that need to be checked.
Also KIPI should be checked. But right now I don't know what to do here.

Andi

Andi,

thanks for confirming the bug. In my opinion the slowness of the system is caused by the fact that a huge number of parallel processes - probably for each slide three processes : "kio_file", "kio_thumbnail", "dbus-launch" - are being spawned. These parallel processes after a short while exhaust all the memory and the system starts paging like crazy. It should be relatively easy to limit the number of slides being processed in parallel to a reasonable number - say 4 - and continue processing in series on chunks of 4 slides. In this case it would still take some time to prepare the slide show, but the system would stay responsive, and after a little while the advanced slide show would start. 

Robert

Probably it would be the best to make some sort of queue to avoid running to many processes.

I think it also should be proved which of the operations are really necessary before the slide show dialog appears. I guess most of them could be done just in time when the slide show is running (for example always prepare the next 2-5 images and keep the same amount of already seen images in memory). And maybe some of the operations can be done with OpenGL (if it is not used till now).

I fixed some memory leaks (but they were not responsible for the slow execution) and some other issues.
It should start a little bit faster, but still there are many strange things going on:

1. Why does this plugin consume over 800MB RAM, just by loading? I have not found an memory leak, so this must be a big misconception.

2. We seem to load the image infos all the time: when starting the plugin, when updating the list, when calling the startSlideShow slot etc. Although we have a sharedData object, we don't seem to use it properly. I guess data is duplicated or even tripled.

3. When the plugin is started and you click in the imageslist, you don't get the correct thumbnails.
Somehow the list is not completely loaded, so something must be active in the background.

4. We still use a lot of Qt3Support classes in this plugin.

5. We check for valid files when we start the slideshow, this takes time again. But why? I guess all files coming from the KIPI-Interface should be valid / existent, so why check this? It slows down the start of the slideshow.

Well that's enough for today, I will continue tomorrow analyzing this pluging.

Andi,

Look like the is a cache mechanism in this plugin. I suspect that it's the problem:

http://lxr.kde.org/source/extragear/graphics/kipi-plugins/advancedslideshow/slideshowloader.h#45

http://lxr.kde.org/source/extragear/graphics/kipi-plugins/advancedslideshow/slideshowloader.cpp#112

Which is a map of KUrl and loaded QImage. It sound like there is no cache limit.

I think you just check how is filled this map. I suspect that current selection is pass is loadedThread, images are loaded as well, and after slide show is started. It's just my viewpoint, after to use slideshow with a huge images selection.

Gilles Caulier

I have no cache enabled (you can set it in the dialog).
We are filling this KUrl map in three different places, and I don't understand why.

First, we get all images from KIPICollection Interface, and find out which are selected:
http://lxr.kde.org/source/extragear/graphics/kipi-plugins/advancedslideshow/maindialog.cpp#552

Then we update this list whenever something happens in the config dialog.
And in the end when the slideshow is loaded, we get this list again, without using the sharedData:
http://lxr.kde.org/source/extragear/graphics/kipi-plugins/advancedslideshow/plugin_advancedslideshow.cpp#192

The strange thing in the code above: We can never get the selected images, so a slideshow will always display a full album. But the slideshow config has a radiobutton to only display selected images (which is always grayed out anyway).
Also in the first code reference, we calculate the images by getting all images from the interface and keeping only those that belong to the current album path.
When the slideshow is started (second code reference), we just ignore all those urls and get the images with interface->currentAlbum.

This looks like a misconception to me, but maybe I don't understand the purpose here.

Anyway if the plugin is caching, it definitely doesn't have to do this on startup, only when pressing "Start Slideshow". And even then it should cache like 4-5 images, not more.

I don't know exactly. Valerio has written this part. I have just polished code to compile fine under Win32.

I'm agree to to complete KDE4 port there. No need to lets Qt3 code until the end of the world. 

And this is true to all other plugins of course...

>Anyway if the plugin is caching, it definitely doesn't have to do this on
>startup, only when pressing "Start Slideshow". And even then it should cache
>like 4-5 images, not more.

I'm totally agree...

Gilles

I guess I found a proof now that the image urls are not used properly:
I fixed the selection radiobutton, so if you select a range of images, you can use it in the advanced slideshow config dialog now.
But if you have selected images and start the slideshow, ALL images are shown again, not the selected ones.
This proofs to me what I have guessed before: we don't use the sharedData properly.

I will try to fix this now, and then check how to avoid the preloading of all the images, especially when the plugin is just loaded.

One possible time and memory saver:
If "start SlideShow" is clicked, we read in information about exif comments and angle of each image, this can take some time.

Suggestion:
Do not read this info when the slideshow is started, but when an image is loaded. This way we don't have to wait so long for the slideshow to start up.

SVN commit 1000030 by aclemens:

Quickfix: Do not create a list of comments/captions and angles when
starting the slideshow, this will be very slow if you have more then 300
images selected.
Instead read this info while images are loaded.

It is a quickfix because we still generate a fake comments and angle
list in slotSlideShow(), but with default values. I did it this way to
minimize code changes. In the future we might want to change the
slideshow classes instead.

Still the plugin wastes a lot of memory on startup, I have not found out
yet what produces this memory consumption.
Will need to do further checks.

CCBUG:182743

 M  +5 -2      plugin_advancedslideshow.cpp  
 M  +4 -2      slideshow.cpp  
 M  +13 -12    slideshowgl.cpp  
 M  +41 -16    slideshowloader.cpp  
 M  +7 -1      slideshowloader.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1000030

SVN commit 1000476 by aclemens:

Add possibilities to set a size for ImagesList widget and
ImagesListView.
The default iconsize was SizeLarge, but this may be to large for
advancedslideshow.
We need something to setup an default iconsize.
ImagesListViewItem will get its iconsize from the associated view, and
ImagesListView and ImagesList widget take an optional size parameter
now.

This commit will also remove the creation of comments and tag
information, because the only plugin that needs it is advancedslideshow
and sendimages. If we add a lot of images to an ImagesList, it can take
a while to add this information.
If a plugin really needs this, it should call updateInformation() on the
ImagesListViewItem now, like sendimages does with this commit.

The next step will be to use ImagesList widget in advancedslideshow, to
factorize code.

CCBUG:182743

 M  +68 -31    common/libkipiplugins/imageslist.cpp  
 M  +26 -10    common/libkipiplugins/imageslist.h  
 M  +2 -0      sendimages/imagespage.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1000476

I have added some commits that fix the memory consumption.
Now loading 5000 images on my computer doesn't allocate over 800MB RAM anymore, yeah! :)
Still the plugin needs more "love", there are things to polish, and thumbnail rendering (throughout digiKam) could be improved as well.

But at least this plugin is usable with many images now.

Robert,
if you have the time, please checkout latest KIPI SVN and tell me if it got better.

I will keep this report open, as there are more things to fix and I'm waiting for you response.

Andi

Andi,

thanks for the information ; sounds good to me
.
Please leave me some time to check out things, I am using a standard
open suse 11.1 distribution here. I would have to install the kipi-svn
version first and also svn version of digikam; but am busy with other
things right now.
I appreciate very much your endeavor.

Robert


Andi Clemens wrote:
> https://bugs.kde.org/show_bug.cgi?id=182743
>
>
>
>
>
> --- Comment #16 from Andi Clemens <andi clemens gmx net>  2009-07-21 18:38:49 ---
> I have added some commits that fix the memory consumption.
> Now loading 5000 images on my computer doesn't allocate over 800MB RAM anymore,
> yeah! :)
> Still the plugin needs more "love", there are things to polish, and thumbnail
> rendering (throughout digiKam) could be improved as well.
>
> But at least this plugin is usable with many images now.
>
> Robert,
> if you have the time, please checkout latest KIPI SVN and tell me if it got
> better.
>
> I will keep this report open, as there are more things to fix and I'm waiting
> for you response.
>
> Andi
>
>

No problem :)
We will release kipi-plugins 0.5.0 this weekend, so the fixed will be in this release.
Also I don't think you need digiKam-svn to use the new kipi-plugins package.

Andi

Robert,

I will close this one. I'm pretty sure it is fixed and some similar bugreport was closed as well, since the user could confirm that memory and performance issues have been fixed.

If you test this bug when you have some more time left still discover the problems described in here, feel free to re-open the report.

Andi

Andi,
I just compiled kipi-plugins-0.5.0 and digikam-1.0.0-beta3 and started
advanced slide show on a collection with some 700 images. Looks like it
is working perfectly now. No delays and I see only one thread. I agree :
problem seems to be fixed now. Thanks again, Robert.

Andi Clemens wrote:
> https://bugs.kde.org/show_bug.cgi?id=182743
>
>
> Andi Clemens <andi.clemens@gmx.net> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|ASSIGNED                    |RESOLVED
>          Resolution|                            |FIXED
>
>
>
>
> --- Comment #19 from Andi Clemens <andi clemens gmx net>  2009-07-30 12:46:41 ---
> Robert,
>
> I will close this one. I'm pretty sure it is fixed and some similar bugreport
> was closed as well, since the user could confirm that memory and performance
> issues have been fixed.
>
> If you test this bug when you have some more time left still discover the
> problems described in here, feel free to re-open the report.
>
> Andi
>
>