Logging out on a LCD produces a fade effect that is not pleasant

could you try with this package :
http://people.ubuntu.com/~seb128/gnome-session_2.9.4-0ubuntu3_i386.deb ?

you need to logout/login after installing the package.

(In reply to comment #1)
> could you try with this package :
> http://people.ubuntu.com/~seb128/gnome-session_2.9.4-0ubuntu3_i386.deb ?
>
> you need to logout/login after installing the package.

Looks like this is a smoother fade.

One problem though, the colors aren't faded equally, which has a side effect on,
say, a nice blue sky. The blue sky becomes a rather unpleasant
shadow-emphasized dark sky, which makes it rather splotchy and like an inverse
or negative of what was there before. Not sure if that's just a side effect of
the image I chose.

I'm not sure to understand the color issue exactly. Do you think that's the
patch is an improvement or that's better without it ?

(In reply to comment #3)
> I'm not sure to understand the color issue exactly. Do you think that's the
> patch is an improvement or that's better without it ?

It is an improvement, but it's not perfect. The fade is closer to what it is on
crt screens, but after the screen has faded, parts of the screen look blotchy.
I'd take a screenshot to show you, but I have no idea how to do that on the
logout screen.

Jonathan

right, I've some weird color on the background too with it.

Marking this bug as an upstream issue, the patch is from this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=140717

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

Sébastien, is there any way to tell GDM to not produce a fading effect at all,
for example darken the screen in just one stroke, like gksudo does currently ?
Or maybe why not, remove the darkening altogether and simply pop-up the log-out
window. IIRC that's what Warty did. Not only would it look better for those
like us, who experience this bug, but that would also make it faster. I don't
know, there must be a conf file for GDM in /etc, or maybe some key in Gconf (not
sure about that...) ? Or some kind of hack or I don't know... soemthing ! ;-)

gdm has nothing to do with that. The fading effect is a gnome-session feature.
Why not fixing it rather than dropping it? That's what the upstream bug I've
pointed is for

(In reply to comment #9)
> gdm has nothing to do with that. The fading effect is a gnome-session feature.
> Why not fixing it rather than dropping it? That's what the upstream bug I've
> pointed is for

Yes, it would be a good idea to at least try out their patch in Gnome 2.11 so
that all Breezy users can test it.
If it's not any better, we can just revert to the current version.
However, if they can't get it right on all decently fast/modern machines, having
an option to remove the fading effect for machines where it will not work, would
be better thab nothing... no ? Or is it technically difficult to toggle the
fading on/off ?
If Gnome won't apply the patch, do you have the freedom to do it just for
Ubuntu, independantly of upstream decisions ?

We can apply a local patch, but this bug is really low priority since that's
just a matter of cosmetic feeling for a 3 second animation on logout. That would
be something to play with for somebody who has some interested to play with
that, try the upstream patch, change the animation values, etc. Setting it as
"easyfix" for people who search an easy bug to play with

(In reply to comment #11)
> We can apply a local patch, but this bug is really low priority since that's
> just a matter of cosmetic feeling for a 3 second animation on logout. That would
> be something to play with for somebody who has some interested to play with
> that, try the upstream patch, change the animation values, etc. Setting it as
> "easyfix" for people who search an easy bug to play with

Don't know how to apply a patch... nevermind re-compile the affected package :-/
Well I did try once, but the patch could not be applied because the source code
of the package in Ubuntu was not exactly the same as what was in the patch, so
the 'patch' command refused to patch the source file.
And even patch worked, I have no idea about the next step... recompiling the
package and making a deb out of it... I guess a simple ./configure && make &&m
checkinstall won't quite do it ?! :o(

so let somebody else working on that, or use google/join the motu IRC chan/read
the debian website on how to make packages to learn how to do and then contribute.

Basically to apply a patch you use "patch -p0 < file.patch", you can build a
package with "dpkg-buildpackage -rfakeroot"

> so let somebody else working on that, or use google/join the motu IRC chan/read
> the debian website on how to make packages to learn how to do and then contribute.

Learning, yeah, I would indeed be apply to 'patch' thing in the future, if just
as part of my Linux learning curve. Now as for contributing to Ubunt, altough
this sounds a marvelous idea, I would too scared of making mistakes and screwing
up people's systems ! :-/

> Basically to apply a patch you use "patch -p0 < file.patch", you can build a
> package with "dpkg-buildpackage -rfakeroot"

Thanks... I looked at the latest patch I found in the upstream bugreport you
mentionned, but sadly, once again, the source code I got from Ubuntu
repositories really doesn't match the patch :-/ I patch is tiny and the source
file not too big, so I had a look at it, and compared with the patch. It seems
that the Ubuntu version is very different. It "looks" the same, but it isn't
really close enough to let me apply the patch, even by hand. Only the last part
of the patch was applicable, I find. I guess patching wouldn't be so difficult,
if only the patches were applicable ! :-/

(In reply to comment #14)

> as part of my Linux learning curve. Now as for contributing to Ubunt, altough
> this sounds a marvelous idea, I would too scared of making mistakes and screwing
> up people's systems ! :-/

Sending patches doesn't break anything for everybody since a maintainer review
the patch before using it for a package ...

> Thanks... I looked at the latest patch I found in the upstream bugreport you
> mentionned, but sadly, once again, the source code I got from Ubuntu

patch from upstream comment #14 apply fines on the current package this code has
not changed for month

This problem is just a tiny bit more than a cosmetic issue. I ran the CPU
monitor before bringing up the logout menu, and hit cancel after the fade effect
(the 3 shade render not really a fade effect). During the fade the mouse is
choppy and going back to the cpu monitor it shows that during every shade blip
of the fade the cpu usage jumps to 100%. This causes the mouse lag and jump.
This kind of IO burden doesn't seem wise :(.

try installing a video driver like the nvidia or ati one. that resolved the same
problem for me

Confirmed upstream and still not really smooth so confirmed here.

Related to Bug #39371 ?

The currently included patch is buggy.
It uses a static variable times_called which should be private for each screen. Therefore, it doesn't work correctly in xinerama setups (usually one screen stops fading earlier and after that the other screen continues to fade for another 16 frames).

The graphical glitches result from the optimization approach of the current patch. It uses 16 frames streched over 1500ms. Every new image is computed from the previous one. Therefore, rounding errors add up, yielding incorrect colors in the final image. However, the speedup is significant compared to the original implementation.

The original implementation computes the correct frames by bending between the start image and end image. However, the computation is redundant.

See my attached patch which implements fading without color glitches. In contrast to the original implementation it uses a lookup table which is precomputed for each frames. It just takes 256 bytes of memory. It is slower than the additive implementation in the current patch, but is faster than the original one. And it doesn't have the bug with multiple screens.

Thank you for the work Christof, bug fixed with this upload:

gnome-session (2.17.92-0ubuntu2) feisty; urgency=low

  * debian/patches/11_session_dialog.patch:
    - updated to show an error dialog when a command run doesn't work correctly
      (Ubuntu: #84858)
  * debian/patches/13_smoother_fading.patch:
    - patch update from Christof Krüger, works fine on xinerama
      and fix incorrect colors being used (Ubuntu: #12389)

It's still looking ugly in Ubuntu 6.04 on my laptop LCD screen - and I'm updating every day.

Do you mean 7.04 (feisty) or maybe 6.06 LTS (dapper)?

When using feisty, you should be able to see a difference.
I don't think that dapper will be updated just because of this bug since this is a rather minor issue.

In case you are not using feisty: If everything goes well and the release schedule will not be altered, feisty will be released on april, 19th.

I'm running feisty. Sorry - I should have mentioned that.

What is the output of the following command?
 apt-cache show gnome-session|grep Version

Could you please make a screenshot? You won't be able to make a screenshot directly when the logout screen is active. But you can do it by using Xnest:

1. sudo apt-get install xnest
2. gdmflexiserver --xnest

This will start a new gdm screen inside a window. You might need to add a new test user first, because gdm usually won't allow you to login twice.

Here is a screen shot of how the background looks when I log out.

the screenshot looks correct

I can imagine that the LCD panel itself (or its controller (or a even the graphics card)) reduces the color depth which is usually not that visible but becomes more prominent with dim colors. Therefore, Duncan Lithgow might even consider the screenshot to be ugly when displayed on his LCD.

Christof - you might be right, but how do we find out? And if it's ugly then it's ugly - the reason is a bit of a side issue. I can't find any GUI indication of what my color depth is, but I seem to remember it being "24" - does that sound right?

On the assumption that you're right I have reopened bug #17561 - that seems the most appropriate place for my problem. Please take a look at the images I've uploaded there.

Please disregard my previous comment. That was a different problem and it's been solved.

When visual effects are off, the fade is smooth on normal->faded.
When visual effects are turned on, when going from smooth->faded it flashes and is bad.