GNOME Bugzilla – Bug 587247
Set _NET_WM_FREEZE_UPDATES initially for override-redirect
Last modified: 2018-02-10 04:39:56 UTC
This patch is a component in fixing a long-standing problem where when an initially mapped override-redirect window (menu or tooltip) might be shown with garbage in it by the compositor, depending on timing. (A hack-around was devised where the contents underneath" a newly shown background-none window were copied into the window's pixmap. AFAIK, this code is present in the upstream X server, but commented out of at least the Red Hat packages because of undesirable side-effects.) I like this solution a lot. The use of an 'existence-only' property prevents races when the window is mapped - the compositor can just fetch the property after selecting for notify. But no round-trips are needed later - the compositor can look at 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 and a repaint 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.) Caveats * Not an agreed upon wm-spec addition, yet. I'll mail wm-spec-list * Not completely clear this should be part of the wm-spec. It has zero to do with window managers, and everything to do with compositing managers. So far we don't have a compositing manager spec or any way for a CM to advertise supported features. * Almost certainly conflicts with the client-side-windows branch, though only trivially.
Created attachment 137518 [details] [review] Set _NET_WM_FREEZE_UPDATES initially for override-redirect When we map an override-redirect window, the compositor has no way of knowing when the contents of the window are safe to display; we might have finished our redraw before the compositor selects for damage at all. Seting a _NET_WM_FREEZE_UPDATES property on such windows tells the compositor to hold off on displaying the window until the property is deleted. gdk/gdkwindow.c gdk/x11/gdkinternals.h: Add _gdk_windowing_window_post_update(), a function that is called on a toplevel after one or more windows within that toplevel have been updates. gdk/quartz/gdkwindow-quartz.c gdk/win32/gdkwindow-win32.c: Stub out _gdk_windowing_window_post_update() gdk/x11/gdkwindow-x11.c gdk/x11/gdkwindow-x11.h: WHen initially mapping an override-redirect windoew, set _NET_WM_FREEZE_UPDATES and clear it when we finish the initial batch of updates within that toplevel. gdk/x11/gdkdisplay-x11.c: gdk/x11/gdkdkisplay-x11.c: Add _NET_WM_FREEZE_UPDATES to the set of atoms we intern initially.
http://mail.gnome.org/archives/wm-spec-list/2009-June/msg00002.html
In thaw_initial_updates + toplevel->updates_initially_frozen = TRUE; should probably be FALSE instead. I also notice that the only use of this flag seems to be to make duplicate calls of _gdk_windowing_window_post_update harmless; but then, why do you do the extra work to keep duplicates out of the updated_toplevels list ?
(In reply to comment #3) > In thaw_initial_updates > > + toplevel->updates_initially_frozen = TRUE; > > should probably be FALSE instead. Yep. > I also notice that the only use of this flag seems to be to make duplicate > calls of _gdk_windowing_window_post_update harmless; but then, why do you do > the extra work to keep duplicates out of the updated_toplevels list ? Basically just because I was thinking "set" not "list". I think it's worth the small amount of extra work in: if (!g_slist_find (updated_toplevels, toplevel)) updated_toplevels = g_slist_prepend (updated_toplevels, toplevel); to keep the encapsulation... if the current x11 implementation of post_update is harmless to be called multiple times, that doesn't necessarily apply to future incarnations or things that might be done in other backends. (My basic assumption is that the number of updated windows might be large, but the number of toplevels will be constrained so the g_slist_find() won't devolve into objectionable quadratic behavior.)
Owen, did you want to scrap this proposal in favour of the extended sync counter idea ?
I'm waiting to get more feedback on the extended sync counter idea. Lubos said he was going to look at it, and I should ask Soeren as well.
Any update on this, Owen ?
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.