On Fri, 2011-05-06 at 18:19 +0300, [email protected] wrote: > From: Ville Syrjälä <[email protected]> > > The composite extension spec says that window background painting > should be inhibited when the subwindow redirection mode is set to > manual. > > This eliminates the ugly flashing effect when compiz unredirects a > fullscreen window.
Being able to do no-flash unredirection is something I'd definitely like to be able to do for Mutter! Hmm, OK, so what you are doing is: - Unmap or reshape COW, leaving root window contents, which you don't want to be repainted. (And you can't get this by changing the background to None because: "Changing the background of a root window to None or ParentRelative restores the default background pixmap.") - Unredirect fullscreen window it took me a moment to see why this isn't backwards ordering: if you unredirected the fullscreen window first it wouldn't have preserved contents, so the X server would have to expose it from scratch. This patch does look like it makes the behavior agree with the composite protocol extension; it's not clear at this point whether there was always a mismatch or whether it was changed at some point: History in the compositeproto repo shows: commit 35a9c80252b35720c1afc5dc53153228e2084b10 Author: Keith Packard <[email protected]> Date: Sun Nov 9 07:07:21 2003 +0000 Note that Manual Subwindows mode disables background painting. but the X server code from that date wasn't easily discoverable for me. Patch looks correct - it makes windows with manual subwindow redirection go through the same codepath as background none windows. It seems pretty safe - very little application painting code *depends* on clearing to the background color, and breakage from this change would require that plus an application that was doing something pretty unusual with the composite extension. Would be definitely good to get Keith to check this as well if possible. - Owen Reviewed-by: Owen Taylor <[email protected]> _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
