GNOME Bugzilla – Bug 140717
Make the fade-on-logout smooth
Last modified: 2007-05-08 10:18:11 UTC
Description of Problem: When logging out of gnome the fadeout is often choppy and gives users a bad impression gnome's performance charateristics. Steps to reproduce the problem: 1. Logout 2. Watch the fadeout. Momentarily I will be attaching a patch to fix this problem.
Created attachment 26912 [details] [review] proposed smooth fadeout patch It has been suggested that this patch might need to be able to drop frames on slow machines. I'll look into whether that's still an issue or if the new code is fast enough that it doesn't really matter.
Created attachment 26937 [details] [review] proposed smooth fadeout patch *Removed unused variables start_pb and start_p. I also tested this on a 650MHz PIII with a 1400x1050 LCD panel (the slowest machine running gnome that I have access to) and the fade out seems fine. It does take a little longer than 1.5 seconds, but it doesn't block the user from logging out and is much nicer looking than the choppy fade IMHO.
*** Bug 137802 has been marked as a duplicate of this bug. ***
*** Bug 112486 has been marked as a duplicate of this bug. ***
Two dupes for this already, so it's about time we confirm (and check in the patch).
It looks kinda crappy here too (Pentium-M @ 600 Mhz) .. its not really fading but getting darker in just 2 steps.
Sorry about this, but the patch has to be updated as it doesn't apply cleanly any more. Could you do that? I promise I'll test it here and report back if you do :-)
I probably won't have time to update the patch until next week. I'll also get my hands on a slower machine to check out what Christian is reporting.
Attaching a reworked patch for HEAD. It doesn't work after Cancelling the logout dialog though so that needs to be looked at. The fadeout is definitely much better with this.
Created attachment 32329 [details] [review] reworked patch
The fade step counter (static) needed to be reset to zero upon completion. The following patch does that. I tested it on my laptop at 600Mhz and 1.6Ghz (1400x1050) and it performed fine in both cases -- though more people should do performance tests. It should be noted that with this algorithm images on the screen tend to get a little bit of an contour map look to them when fading. I don't think that it's a big problem for sake making the fade smoother.
Created attachment 32714 [details] [review] reset fade counter
Could you attach a patch in diff -up format? Also, was this incremental to the previous patch?
Sorry about the format -- I've gotten to used to using svn. The patch is against cvs HEAD. Re-attaching below...
Created attachment 32721 [details] [review] reset fade counter
Is this on top of the other patch or a rewrite of it or? :-) Maybe attaching an incremental patch too would be nice just to see what you actually changed from the previous patch.
As I said in comment #14, it's against cvs HEAD (using cvs diff -up logout.c). I will attach an incremental patch showing differences between the reworked patch that you posted and the new one -- almost nothing has changed.
Created attachment 32728 [details] [review] incremental patch between reworked and reset fade counter
Does this work correctly for you? I got some strange delays when logging in and hitting logout right away. It did nothing for a minute or two and then suddenly started throwing logout dialogs at me... Second time I tried it hung.
That sounds pretty bad. I haven't seen that behavior in my testing. I'll try applying the patch to a fresh cvs checkout to limit other factors. Has anyone else had a chance to test this?
Giving this a go again to see if I can find out what broke.
I can't get it to break now, so that was probably some other bug in an earlier release. Maybe we can get this in now then? Anyone able to test this on Solaris and maybe even a SunRay server?
maybe this patch could be pushed now?
Still hasn't had anyone test the implications on network traffic or cpu usage on big servers with a lot of users. I don't know whether we should cater for those unless someone who are running something like that actually wants to test the patch...
This needs pushing now, it has been over a year and the bug is appearing often in other distros bugzilla's downstream. The wasted time it takes to keep repatching patchs is just silly.
Yeah, it needs pushing and we need someone to get this tested on for example a SunRAY or plain X server with many users on it to see if it works without a big impact on performance in these environments. Glynn or Calum could help maybe...
Any recent work on this?
Arg, cut of the rest of the comment...xscreensaver seems to have a very nice fade mechanism, maybe this could be duplicated here?
Just a comment, could animatine the fading the logout display be automaticly disable when being used on a remote (xdmcp) display, as the fade out process takes a long time over the network, particularily with older/crappy x servers (aka winaxe)? Or should that be another bug report?
Keeping just the patch that contains the full and updated change.
What I don't understand is why the GDK/Cairo/RENDER alpha blending capabilities aren't used for the fade effect. That would take advantage of hardware acceleration and should work equally well remotely, e.g. (With a compositing manger, it would be even easier, just create a suitably coloured solid window and change its translucency :) Re: comment #28: xscreensaver fades out by changing the colourmap, so the logout dialog would be affected as well. I doubt that'd be useful. :)
Whatever solution is chosen, it needs to work, degrade, or simply butt-out for network X sessions. It isn't just on old hardware that this is a problem.
We use the patch in Ubuntu and it works nicely although some people noticed some quirks regarding the faded out colours: https://launchpad.net/distros/ubuntu/+source/gnome-session/+bug/39371
The strange colours are still there, especially on LCD screens. Gnome 2.16.1 Ubuntu 6.10
Daniel: does Ubuntu with LDTP use this patch? Or do they disable it?
I've uploaded a patch downstream. I changed the original implementation by using a lookup table This should be faster because it just needs one lookup operation per channel per pixel. It also saves som memory since there's no need for the end frame pixmap any more. http://librarian.launchpad.net/6582374/13_smoother_fading.patch
The patch is faster than what we had, so it really can't make things worse. I committed it.