Freezing updates for compositing managers

[Owen Taylor <otaylor redhat com>]

There is a long-standing problem where when an initially mapped
override-redirect window (for example, menu or tooltip) it can
be displayed by a compositor before the application has a chance
to draw the contents.

This is most acute when the application has unset the background
to try and avoid an initial flash, since the contents of the
pixmap are then garbage.

(There's hack-around for this in the Xorg code where if you
map a background-none window, the contents of the composite pixmap
are initialized from the server's guess at what is under the
window. This code is commented out of at least the Fedora packages
because of undesirable side-effects.)

Fixing this really requires application intervention - when the
compositor receives the MapNotify for the window the window might
have drawn yet, or might not, and there's no way that the
compositor can know.

This is actually a symptom of a more general situation - an
application wants to make multiple X requests (here a map and
then the redraw) and not have the compositor draw until it is done.

Thinking of it that way - that gives a pretty straightforward
solution - the app can set a property that says "don't update me" -
say _NET_WM_FREEZE_UPDATES - and then remove it when it is ready
to be painted again.

Making the property have that meaning just by its presence is a 
little unusual compared to existing practice, but has some nice
properties:

 - because its a property, the window manager can figure out the
   status on a newly mapped window without race conditions by 
   first selecting for PropertyNotify then checking if the property
   exists.

 - because we don't care what's in the property, PropertyNotify
   events are enough fore subsequent updates - just check whether
   XPropertyEvent.state is PropertyNewValue or PropertyDelete

The same mechanism could be reused for freezing updates while a
window is shown:

 - To make a scroll (with CopyArea) and then repainting the
   newly scrolled in area atomic.

 - To allow not using a backing pixmap at all for redraws when
   a compositor is present! (caveat: depending on how the compositor
   is selecting for damage, it might get flooded with events
   hurting performance.)

Patch implementing this for GTK+ for newly mapped windows:

 http://bugzilla.gnome.org/show_bug.cgi?id=587247

Patch implementing it for Mutter:

 http://bugzilla.gnome.org/show_bug.cgi?id=587255

Main question for me is whether this belongs in the wm-spec and
should be called _NET_WM_* ... it's clearly compositing-manager
specific not window manager-specific, but there's not really
(as far as know) a good alternate location.

- Owen