After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 587247 - Set _NET_WM_FREEZE_UPDATES initially for override-redirect
Set _NET_WM_FREEZE_UPDATES initially for override-redirect
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-06-29 00:51 UTC by Owen Taylor
Modified: 2018-02-10 04:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Set _NET_WM_FREEZE_UPDATES initially for override-redirect (7.79 KB, patch)
2009-06-29 00:53 UTC, Owen Taylor
none Details | Review

Description Owen Taylor 2009-06-29 00:51:29 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.
Comment 1 Owen Taylor 2009-06-29 00:53:44 UTC
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.
Comment 3 Matthias Clasen 2009-06-29 03:24:59 UTC
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 ?
Comment 4 Owen Taylor 2009-06-29 17:34:01 UTC
(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.)

Comment 5 Matthias Clasen 2009-07-03 04:29:10 UTC
Owen, did you want to scrap this proposal in favour of the extended sync counter idea ?
Comment 6 Owen Taylor 2009-07-13 13:02:42 UTC
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.
Comment 7 Matthias Clasen 2009-11-27 23:00:21 UTC
Any update on this, Owen ?
Comment 8 Matthias Clasen 2018-02-10 04:39:56 UTC
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.