Bug 190632

Summary: On startup, shows a modal dialog: "Finding images for the wallpaper slideshow"; takes minutes to finish(plasma frozen during this time)
Product: [Unmaintained] plasma4 Reporter: Shaun Reich <sreich>
Component: generalAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: airfullbete, andresbajotierra, aseigo, ash.hunter, dpalacio, npiguet, rainer
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Shaun Reich 2009-04-25 16:42:18 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

Hello;

I have the following problem, which occurs both when plasma is started(any time), and when I right click the desktop and select "Desktop Settings".

Plasma then shows a modal dialog, that says that it is finding the images for the wallpaper slideshow. During this time, Plasma is locked (hence modal dialog).

Since I have thousands of images, this process takes several minutes.

It is also annoying, how this doesn't just do it once or anything, it occurs all the time, so this really decreases startup time, and makes plasma take forever to finish restarting itself (after a crash).

Here is an image, this is when I discovered that the Desktop Settings dialog does this also...

http://picasaweb.google.com/predator106/KDE4Screenshots#5328637154527673682

Obviously, I have a slideshow setup.

I really don't see why it is necessary to do this, unless it is trying to find images that it hasn't used before... in which case, it needs a much more efficient way for this to happen.
Comment 1 Aaron J. Seigo 2009-05-13 02:14:12 UTC
SVN commit 967239 by aseigo:

* use a local event loop rather than calling process events on the main loop; this keeps the ui refreshing while allowing us to avoid being interupted; still modal but a step int he right direction
* speed up collecting papers by ~36x
* only allocate packages in the Image class when we need them, and no more than one at a time ==> much, much less memory usage. much.

the model still isn't as efficient as it could be.

result: a 91 directory, 3200 images and 84 packages collection drops from ~14.5s to ~0.4s, or ~97% off of the run time.
the model, in contrast is about twice as slow, or ~.8s.
cold caches and other variants may invoke the usual YMMV.
BUG:190632


 M  +89 -71    backgroundlistmodel.cpp  
 M  +31 -5     backgroundlistmodel.h  
 M  +18 -18    image.cpp  
 M  +2 -1      image.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=967239
Comment 2 Pino Toscano 2009-05-13 02:24:49 UTC
*** Bug 192048 has been marked as a duplicate of this bug. ***
Comment 3 Pino Toscano 2009-05-13 02:24:58 UTC
*** Bug 192467 has been marked as a duplicate of this bug. ***
Comment 4 Dario Andres 2009-08-11 23:34:12 UTC
Bug 203371 seems to be experiencing this issue again on 4.3.0 ...
Regards
Comment 5 Shaun Reich 2009-08-12 03:15:23 UTC
Intresting..fwiw, after this commit, it was *very* fast compared to what it was before, but it is still obstructive. It is still quite noticeable, and will be there for a few seconds (last time I checked after that commit).

Still needs some work I feel, I turned off the slideshow..Ideally it should be transparent when changing backgrounds.. but as Aaron stated, some users were wondering why Plasma was locked up for so long...can't win :)
Comment 6 Nicolas Piguet 2009-08-12 23:07:06 UTC
Kde 3.0 has brought a little bit of an improvement of speed for me, but it's really not that noticeable. I also switched off the slideshow wallpaper for now. The initial picture lookup takes about 20 seconds, and all the subsequent ones still take anywhere between 7 and 10 seconds. 

Isn't it possible to really load that list in a background thread? If it isn't possible at startup, then a suitable workaround may be to load only the first 50 or so pictures inside the UI thread, and then add the remaining ones later, from a low priority thread.

I might just be pushing it with over 11'000 pictures in 115 subfolders.
Comment 7 Nicolas Piguet 2009-08-12 23:13:35 UTC
I'm actually wondering if building the list of files is necessary at all. Instead of building the whole list and then taking a random picture from there, why not just recursively pick a random folder (or picture) starting at the slideshow's root directory until we end up on a picture.

The disadvantage is that some pictures would be more likely to show up (right now, each picture should have an equal probability to be displayed), but does it really matter? The bias in the probability distribution is most likely not going to be very noticeable, and even if it is, it would only be a very minor disturbance compared to the current problem.
Comment 8 Shaun Reich 2009-08-13 00:48:09 UTC
That was precisely what I was wondering, I don't understand why each picture (or whatever, I forget what it does exactly), be put into "packages"... I don't understand why the "packages" need to be used at all, like Nicolas said, it should just be picking a random picture from $sourceDir and all of it's descendents.

Yeah, the randomness would only be noticeable that it is lacking, if you have a very small collection (<500 even).

Reopening, this is not fixed..needs more work, be it a redesign or more optimizations.. or both ;-)
Comment 9 Dario Andres 2009-08-19 05:06:02 UTC
*** Bug 203371 has been marked as a duplicate of this bug. ***
Comment 10 Ash Hunter 2010-03-04 12:33:20 UTC
I really would like there not to be a dialog box popping up at all when I use slideshow as my background. Why can't it find a single image at random (or better: remember its state/last image between restarts of Plasma), display that first one straight away, then in the background at low priority keep topping up the list-to-display with new images?

I don't, and shouldn't care about the fact that it is searching through my many thousands of images. Just do it quietly please!

KDEMod 4.4.0
Comment 11 Shaun Reich 2010-03-04 23:56:12 UTC
Resolving to fixed, I am now content.
Comment 12 Ash Hunter 2010-03-05 00:08:06 UTC
I'm sorry, what? Why are you now content? I certainly am not because that unnecessary dialog box locks me out of my desktop for almost a minute at startup!
Comment 13 Aaron J. Seigo 2010-03-05 01:15:12 UTC
@Ash: it's better than just sitting there with nothing painting, locked and no feedback, right? that's what we had before.

personally, i'm not interested in working on this further. 10k images in a slideshow is an edge condition; we get bug reports when it always starts at the same image (makes sense when you think about it: what's the point of a slideshow that lasts an hour between slides if it always shows the same image on start; random should mean random).

if someone wants to submit a patch that threads the loading of the wallpaper list and/or improves performance of the current code further, that is of course welcome.

"plasma is not infinitely scalable" isn't a particularly interesting br though, tbh.
Comment 14 David Palacio 2010-03-05 02:43:12 UTC
@Aaron
This looks random enough for an initial picture to me:
//Comment #7 from Nicolas Piguet
"Instead of building the whole list and then taking a random picture from there, why not just recursively pick a random folder (or picture) starting at the slideshow's root directory until we end up on a picture."


What bug reports? (I see some very old bug reports, nothing else). It has always been random enough for me (using Plasma since 4.0).
Comment 15 Ash Hunter 2010-03-05 09:19:09 UTC
@Aaron
Yes it obviously is better than no feedback at all, but I think threading this list creation in the background is absolutely needed. I don't believe pointing it at all of my travel photos from the last few years is really an "edge condition", and even for everybody else who has much less photos the box will still pop up which doesn't look great on startup.

And this BR has nothing to do with "plasma is not infinitely scalable": it's that plugins to plasma shouldn't be blocking on everything else where it is possible that an operation they are performing may take a long time. Telling someone "you shouldn't have lots of photos in your slideshow" isn't really a way to solve that. And nor is having a dialog box that says "sorry I'm blocking your desktop right now!"  :)

Now my main problem right now is that this bug should not be closed, especially as quite a few others have been marked as duplicates of this one. Could someone please reopen it, or should we create yet another one?

Ultimately yes, a patch is needed to fix this - the quickest way would obviously be for someone who is familiar with the code already (please!) but if not I'm sure someone will eventually hack one together.