Fixing the flicker problem when toplevel windows pop up over a running screensaver

["Ray Strode" <halfline gmail com>]

Hi guys,

So while at GUADEC, Alex Larsson and Bryan Clark asked me about the
feasibility of setting up GDM to autologin a user at boot up and then
immediately lock the screen.

The idea is that someone owns a laptop that only that person users,
they go to boot it up in the morning and while its booting go to get
coffee or something.  When they come back it would be neat if the
session was already loaded and just needed to be unlocked.

Anyway, I briefly looked into the idea and came up with one bit of
unpleasantness.  As everything loads..the gnome-session splash screen,
nautilus, the panel, etc, there is a lot of flicker as each window is
raised and then the screensaver window is re-raised.

There are two ways to fix this I think:

1) Use the composite overlay window
2) Use the MIT x screensaver extension

Both provide an overlay window that is always on top.  Note, the first
one won't work if the user is running a compositing manager because
the compositing manager will already be using the window for it's own
drawing.

I don't remember all the problems with the screensaver extension that
has prevented its use in gnome-screensaver before, but I kind of
vaguely remember two issues:

1) No way to do fade in
2) No way to run different screensavers on different monitors

I played around a bit during the last couple of days of GUADEC and
wrote a lame little test app that comes up with solutions for those
two problems.  You can get it with

git clone git://anongit.freedesktop.org/~halfline/test-screensaver-extension/

It solves the first problem by making the screensaver window have a
None background pixmap so that when the screensaver window gets mapped
the contents that were on screen stay on screen.  It does mean you
won't see windows update during the fade in, but that could be fixed
if a compositing manager is running by giving the window an alpha
value I think (although I didn't try yet).

It solves the second problem by not actually using the screensaver
window, but instead creating child windows on the screensaver window.

Note, the test app isn't anything but an example program to show that
those two problems are fixable.  The app doesn't do a real-time fade
animation (it just paints progressively darker in a loop basically),
it doesn't show anything interesting while active, etc.

Jon, can you think of other problems that made the screensaver
extension infeasible?  I sort of vaguely remember Keith saying the
screensaver extension was supposed to break grabs, but that ended up
being unimplemented.  Was there some impedance mismatch between its
concept of idle and gnome-screensaver's concept of idle?

--Ray