GNOME Bugzilla – Bug 587255
_NET_WM_FREEZE_UPDATES: allow a client to freeze updates
Last modified: 2012-10-04 03:47:07 UTC
This patch is intended to fix problems with newly mapped override-redirect window showing up with garbage, as well as adding a general facility that could be used for other things later. (The first two patches lay the groundwork, the third adds the feature.) See bug 587247 for a GTK+ patch that sets _NET_WM_FREEZE_UPDATES on newly mapped windows, and more detailed discussion of the approach.
Created attachment 137530 [details] [review] Remove unused public window-property functions Simplify the set of window-property functions to remove the unused functions: meta_window_reload_properties_from_xwindow() meta_window_reload_properties() And to make: meta_window_reload_property() static. The code is considerably simplified by removing the plural variants.
Created attachment 137531 [details] [review] Add META_PROP_VALUE_EXISTS An existence-only property can be used by the client to signal a state with the advantages that: - it is safe against race conditions as the window mapped. (since we can query it after selecting for notification) - there are no round-trips for subsequent updates, since XPropertyEvent.state will be PropertyNewValue or PropertyDelete Noticing PropertyDelete also gives a not-very-important optimization for other properties.
Created attachment 137532 [details] [review] _NET_WM_FREEZE_UPDATES: allow a client to freeze updates Support a new client property _NET_WM_FREEZE_UPDATES which means "don't update this window until I delete the property" The primary purpose of this (for now) is to prevent showing garbage when an override-window has been mapped but not yet redrawn. * window-props.c: Add support for reading the property intially and later. * window-private.h window.c: Add flags for the two reasons that updates could be frozen (resizes and client request), and add meta_window_updates_are_frozen() to check whether updates are frozen so the compositor can get its initial state. * Rename mutter_compositor_set_updates() to mutter_compositor_set_updates_frozen() to avoid having reversed * Implement update freezing in the Clutter-based compositor * Hide the shadow when contents aren't yet available so that a newly mapped menu doesn't show up as a tiny shadow before drawing properly. As currently implemented, a downside is that when a window is shown with no contents yet the actor will be shown, causing the scene to be redrawn with the invisible actor, and delaying the time when we redraw with the real contents. It would be better to hold off on showing the actor (and starting any effects) until contents become available.
This both makes good sense to me and looks good; no objection to committing this.
Owen, I think the first two patches should be committed regardless of what will happen with the _NET_WM_FREEZE_UPDATES proposal.
*** Bug 615120 has been marked as a duplicate of this bug. ***
Is this something that we still need/want?
Review of attachment 137530 [details] [review]: Surprisingly, this still applies and makes for a good cleanup.
Created attachment 218773 [details] [review] Remove unused public window-property functions Simplify the set of window-property functions to remove the unused functions: meta_window_reload_properties_from_xwindow() meta_window_reload_properties() And to make: meta_window_reload_property() static. The code is considerably simplified by removing the plural variants.
Comment on attachment 137532 [details] [review] _NET_WM_FREEZE_UPDATES: allow a client to freeze updates Obsoleted by more complete work on frame synchronization
Comment on attachment 218773 [details] [review] Remove unused public window-property functions I'll take Jasper rebasing and reattaching this as an "accepted commit now", and pushed it so I could dup the bug on my frame synchronization work once I file that. Attachment 218773 [details] pushed as c02e1b6 - Remove unused public window-property functions
Marking as a duplicate of a newly file patchset implementing a more recent proposal from my about how this should work - not just getting atomic updates working, but also getting compositor <-> application synchronization in place. *** This bug has been marked as a duplicate of bug 685463 ***