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: | general | Assignee: | 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
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 *** Bug 192048 has been marked as a duplicate of this bug. *** *** Bug 192467 has been marked as a duplicate of this bug. *** Bug 203371 seems to be experiencing this issue again on 4.3.0 ... Regards 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 :) 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. 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. 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 ;-) *** Bug 203371 has been marked as a duplicate of this bug. *** 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 Resolving to fixed, I am now content. 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! @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. @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). @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. |