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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
