GNOME Bugzilla – Bug 339090
Pictures folder screensaver takes a very long time to show an image
Last modified: 2006-07-31 18:22:06 UTC
Please describe the problem: When running the Pictures folder screensaver in the preferences windows everything seems to work fine. The pictures nicely fade in - not too slow or too fast. However when the screen as actually locked and the screensaver goes fullscreen the pictures take ages to display fully. It is actually possible to clearly see each iteration of the drawing process. The f-spot photos screensaver does not suffer from this problem. And the initial fading from desktop to blank screen also progresses fine. Steps to reproduce: 1. Set screensaver to Pictures folder 2. Lock screen 3. Watch as the pictures take a very long time to get fully drawn. Actual results: Expected results: Does this happen every time? Other information:
It looks like the f-spot slideshow doesn't use cairo and seems to limit the size of the images so that might account for some of it. I'm sure there is room for improvement in the g-s one. Want to give it a try? I'd like to stay away from GL for now, not have more than 2 pixbufs in memory at once, and continue to use cairo if possible. Other than that I'm open to ideas. Thanks.
Created attachment 65946 [details] [review] proposed patch This patch (against trunk as of about six hours ago) improves the performance considerably and removes the progressiveness of the update (line going down the screen), although it does still peg the CPU on my machine while fading. I described the changes inside a proposed ChangeLog entry within the patch (although it's probably not formatted correctly for a patch contributed by somebody without GNOME CVS access). (I've been testing this by running slideshow from the command line, rather than via the screensaver.)
Created attachment 65980 [details] [review] proposed patch Same as previous, with added: + cairo_surface_destroy (surf); so it doesn't add a memory leak.
Hmm, this version is dramatically slower (ie. choppy) for me. Also it doesn't clear the sides where image2 doesn't overlap image1. I'll attach a screenshot.
Created attachment 66013 [details] screenshot showing image not cleared
Probably reverting the changes to fix the fade algorithm (which is currently very strange) will fix whatever the performance problem for you is; I'll put up a patch to fix when I'm home in 16 hours, hopefully. Fixing the fade thing shouldn't be too hard (probably best done when building the pattern), but the revert in the previous paragraph should fix it as well. Note that this version is dramatically faster for me; that shows how different the performance of different X servers is.
So it turns out that fixing the memory leak cost me the entire perceived performance gain; I didn't retest performance after writing the memory leak fix. It also suggests that the performance benefit to me actually came largely from cairo caching something, or causing something to be cached in the X server, or leaking in such a way that it changed the way it did things, not the cost of the GTK image munging. For what it's worth, profiling (with callgrind) shows that my patch should have helped. But the vast majority of the CPU time both before and after my patch is spent in the X server. So the patch only reduces (probably by around 30%, for the images I'm testing on) the nearly-irrelevant amount of time spent in the slideshow process itself. My guess is that it's the double-buffering changes that hurt the performance for you, but it could be something else. Since it seems the double-buffering hurts the performance for you, I wrote code to make the fade linear without doing double buffering; the way to do this is just to leave the current code but set alpha2 in a more complex way. So now I have three patches that are effectively subsets of each other, from smallest to largest (although they're not intrinsically related, except for stepping on a lot of the same code): 1. Make the fade linear (without buffering) by setting alpha2 as described above. This shouldn't affect performance, and improves the appearance. 2. Make only the client-side performance improvement in the previous patch without adding any buffering (which I was doing primarily to fix the fade algorithm). This should improve the non-X-server time by about 30%, according to the profile I took (although it's not that important, at least given my current X server; it could be useful for others assuming it wasn't somehow the cause of the regression you saw). This might make it faster for you, but won't significantly affect the performance problem I see. 3. Do the alpha compositing into an *image buffer* (which presumably doesn't require X server round trips for X servers that don't support drawing pixmaps with alpha). This actually significantly improves the performance problem I'm seeing. If (3) still isn't acceptable (it's actually faster for me, like the first patch I attached was, and unlike the second patch I attached, although it's still a bit slow), I could file (1) or (2) as separate bugs.
Created attachment 66094 [details] [review] patch (1) described in comment 7 - make fade linear
Created attachment 66095 [details] [review] patch (2) described in comment 7 - also fix insignificant client-side performance problem
Created attachment 66096 [details] [review] patch (3) described in comment 7 - also use an image buffer to fix performance problem
First of all, thank you so much for working on this. I really appreciate it. The third one (v8) is still much slower for me. Which is interesting and I'd like to understand why. The second one (v5) seemed fine to me. I'm not seeing much of a performance difference here but the fade does seem nicer. So, I've committed that one to HEAD. Perhaps adding some profiling points to the code would help. I'll do this now. What kind of video card/driver are you using?
(In reply to comment #11) > What kind of video card/driver are you using? ATI Technologies Inc RV350 [Mobility Radeon 9600 M10], with xorg's radeon driver.
I've committed some baseline profiling code to HEAD. Can you give it a try? 2006-05-24 William Jon McCann <mccann@jhu.edu> * savers/gste-slideshow.c: (gste_slideshow_real_configure): Add profile message for configure events. 2006-05-24 William Jon McCann <mccann@jhu.edu> * savers/gs-theme-engine.[ch]: (_gs_theme_engine_profile_log): Add some profiling API. * savers/gste-slideshow.c: (push_load_image_func), (start_new_load), (start_fade), (finish_fade), (update_display), (process_new_pixbuf): Use profiling API. Can be used by: strace -ttt -f -o /tmp/logfile.strace ./slideshow python plot-timeline.py -o prettygraph.png /tmp/logfile.strace The plotting script can be found here: http://primates.ximian.com/~federico/docs/login-profile/plot-timeline.py
I usually use the proprietary nvidia driver. When I tried using the xorg nv driver I saw this performance problem. So, even though this makes makes things worse when using an accelerated driver I've commited this third patch to HEAD.
Small regression in HEAD from these patches is that when resizing the preferences dialog the preview doesn't fill the drawing area.
Created attachment 66838 [details] plot of profiling (proprietary driver, window at 1920x1085) Each of the paint calls takes a fairly significant amount of time which accounts for the poor performance.
FWIW, I tried the unpatched (by the patches here) screensaver with the proprietary driver, and it was just as slow as with the open source driver.
Created attachment 67009 [details] [review] use a similar surface as buffer I've committed this to HEAD and it seems to help with the performance problem that I described in my last comment. Do you see any effect, good or bad?
I tried something like that, and I recall it was considerably slower; I also recall using ...COLOR_ALPHA rather than just COLOR caused significant correctness problems.
(Essentially, I suspect the problem there is the same as what I suspect is the problem with the original code -- that you're creating a surface on the X server; when compositing with alpha requires manual compositing, you then have to ask the X server for the bits of what you're compositing into, and that's a significant part of what slow.)
I think you're right about both COLOR_ALPHA and create_similar. I've changed COLOR_ALPHA to COLOR. However, I'm not sure what to do about the performance problem. Using an image buffer makes the performance unacceptable for me. Can this be improved? For now I've kept the create_similar stuff and added a crude FPS calculation that will disable the fade if it is too slow. The calculation is kinda broken since it only uses one iteration but using more, at least in the worst case, caused too much delay. Bummer. Maybe it is time to look at glitz.
It seems to me like it might be better to revert the cairo_surface_create_similar change and the differences between patch (2) and (3) above. I think that all the two together do is give you double-buffering for drawing code where you never draw a state that's not acceptable to show the user. I think trying to figure out whether the fade can be done acceptably is probably the best way to go; I was thinking of trying to write a patch for that at some point.
Mentioned this briefly to Carl Worth and Keith Packard at GUADEC and they seemed to think this was the right way to do it. If it isn't currently fast enough they want to try to make it faster in Cairo. They would like a canned test-case that prints out a FPS figure. I'll close this bug as fixed.