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 693833 - Fixes for _NET_WM_FRAME_DRAWN
Fixes for _NET_WM_FRAME_DRAWN
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2013-02-14 18:47 UTC by Owen Taylor
Modified: 2013-02-14 21:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
MetaWindow: fix detecting the response to an extended _NET_WM_SYNC_REQUEST (1.34 KB, patch)
2013-02-14 18:47 UTC, Owen Taylor 		committed Details | Review
Fix corner cases where _NET_WM_FRAME_DRAWN might be missed (9.27 KB, patch)
2013-02-14 18:47 UTC, Owen Taylor 		needs-work Details | Review
Fix corner cases where _NET_WM_FRAME_DRAWN might be missed (9.27 KB, patch)
2013-02-14 19:11 UTC, Owen Taylor 		committed Details | Review

Description Owen Taylor 2013-02-14 18:47:19 UTC 
The first patch here fixes a problem where interactive resizes are
completely broken with the current GTK+ wip/frame-synchronization
branch. The second patch fixes a potential bug where a spontaneous
update in a interactively resized window could cause a missed
_NET_WM_FRAME_DRAWN and thus a hang. (Not actually reproduced.)
Comment 1 Owen Taylor 2013-02-14 18:47:21 UTC 
Created attachment 236116 [details] [review]
MetaWindow: fix detecting the response to an extended _NET_WM_SYNC_REQUEST

During resizing, An odd counter value (indicating the beginning of a frame)
shouldn't cause us to redraw and start a new frame, only an even counter
value. This was causing the frozen state for the window frame counter to
overlap the frozen state for the resize, causing the window not to be
updated.
Comment 2 Owen Taylor 2013-02-14 18:47:24 UTC 
Created attachment 236117 [details] [review]
Fix corner cases where _NET_WM_FRAME_DRAWN might be missed

The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.
Comment 3 Jasper St. Pierre (not reading bugmail) 2013-02-14 18:50:37 UTC 
Review of attachment 236116 [details] [review]:

OK.
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-02-14 18:53:02 UTC 
Review of attachment 236117 [details] [review]:

::: src/compositor/compositor.c
@@ +762,3 @@
+    return;
+
+  meta_window_actor_set_updates_frozen (window_actor, no_delay_frame);

Uh, did you mean to call meta_window_actor_queue_frame_drawn here?
Comment 5 Owen Taylor 2013-02-14 19:11:06 UTC 
Created attachment 236126 [details] [review]
Fix corner cases where _NET_WM_FRAME_DRAWN might be missed

Corrected version (I think I restarted gnome-shell on the wrong computer
when testing...)
Comment 6 Jasper St. Pierre (not reading bugmail) 2013-02-14 19:18:50 UTC 
Review of attachment 236126 [details] [review]:

OK.
Comment 7 Owen Taylor 2013-02-14 21:22:45 UTC 
Attachment 236116 [details] pushed as aeb589c - MetaWindow: fix detecting the response to an extended _NET_WM_SYNC_REQUEST
Attachment 236126 [details] pushed as 5876f2e - Fix corner cases where _NET_WM_FRAME_DRAWN might be missed