The problem is also how this would interact with mutter/gnome-shell's startup, as it takes ownership of the "screen".

My basic feeling is that if we can avoid it, nothing should touch the screen until gnome-shell is running and has redirected the screen. Then arbitrary visual effects and niceness are possible. (May be ambitious for 3.0, not really sure about all the pieces in the startup sequence at the moment)

I think this is somewhat similar to bug 639377

g-s-d already has code to do the crossfade effect if nautilus isn't running.

it could be that code isn't working, for whatever reason, though.

If it is broken , we should either fix it or disable it (cf comment 2)

So I just commited this patch:

http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=5cb80995b6899c6ed185797333b709ea9342de42

which fixes an unrelated problem I noticed while looking into the issue.

Created attachment 180341 [details] [review]
gnome-bg: force property update when doing new crossfade frame

gnome-shell needs to get notified about animation updates.

This commit frobs the property to wake mutter up.

After discussion on IRC with owen and cosimo I came up with the above patch. 

Unfortunately, I can't test it, because with or without that patch selecting backgrounds in background capplet makes my X server tank if gnome-shell is running. I haven't figured out the details of why yet.

Review of attachment 180341 [details] [review]:

::: libgnome-desktop/gnome-bg-crossfade.c
@@ +382,3 @@
+                         gdk_x11_get_xatom_by_name ("_XROOTPMAP_ID"),
+                         XA_PIXMAP, 32, PropModeAppend,
+                         (guchar *) &zero_length_pixmap, 0);

Can't you just pass NULL here? X couldn't dereference this, could it, since the length is zero?

Looks like a bunch of dri drawable lifecycle fixes are going in now:

http://lists.x.org/archives/xorg-devel/2011-February/018936.html

(In reply to comment #8)
> Review of attachment 180341 [details] [review]:
> 
> ::: libgnome-desktop/gnome-bg-crossfade.c
> @@ +382,3 @@
> +                         gdk_x11_get_xatom_by_name ("_XROOTPMAP_ID"),
> +                         XA_PIXMAP, 32, PropModeAppend,
> +                         (guchar *) &zero_length_pixmap, 0);
> 
> Can't you just pass NULL here? X couldn't dereference this, could it, since the
> length is zero?

Yea, I think so.

[Removing GNOME3.0 target as decided in release-team meeting on March 03, 2011. "nice-to-have" categorisation for GNOME3.0]

Maybe time to revisit this again, Ray ?

probably 3.4 material at this point, which is good, because we definitely don't want to ship a fade effect that will make people with slightly old X servers crash their sessions.

fwiw, I just gave this patch a go, and it wasn't sufficient. I didn't dig deeper.

Attachment 180341 [details] pushed as 575354e - gnome-bg: force property update when doing new crossfade frame

not sure why i pushed the patch that was insufficient and not sure why i closed the bug. reopening.

I think this is fixed, with the zoom-in animation we have now.