GNOME Bugzilla – Bug 783293
maximized and snapped windows are not refreshed
Last modified: 2017-06-06 13:37:48 UTC
Maximized and snapped windows become unresponsive after some time. I don't know yet how to reproduce it reliably. But it happens quite often. Everything comes back to normal when I unmaximize them. When snapped windows get in this state, they stay on top (when I move other windows they stay behind it). It looks as if there was a snapshot of the window stuck on top of the screen. The applications don't seem to freeze. I am using Xorg and Intel SNA. I think it has been introduced by the new maximize/umaximize animation https://bugzilla.gnome.org/show_bug.cgi?id=766685
It also happens with Intel UXA and modesetting. To reproduce it : - open two windows - snap one the side of the screen - move a part of the other window over the snapped window - click on each windows alternatively until the snapped one freezes and stays on top It can happen on the first try, but can also take a while.
It seems it doesn't affect every app. Here is a better test case : - open two gnome terminals - snap one to the one side of the screen - move a part of the other window over the snapped window - select alternatively each window by clicking on their titlebars until the snapped one freezes and stays on top It also stays on top of the overview mode and full screen apps.
Created attachment 353113 [details] [review] window: Cancel size change effect when no resize took place For size change animations, plugins rely on the size change effect being followed by size changed signal (or effects being kill altogether). However the size changed event is currently only emitted when the compositor syncs the window geometry, which is only done when the move_resize operation resulted in an actual change. To avoid stuck animations, add a new compositor method to signal the end of a size change effect without the syncing work, and use it when a move-resize operation didn't result in a geometry change.
Review of attachment 353113 [details] [review]: Did you find out the exact conditions under which we fail to call sync_window_geometry() ? I thought META_MOVE_RESIZE_STATE_CHANGED would still catch all the cases that don't change the MetaWindow geometry. ::: src/core/window.c @@ +3755,3 @@ + did_placement); + else + meta_compositor_cancel_size_change_window (window->display->compositor, This breaks wayland client resize animations because those really need to wait until the client commits the new buffer. Does the issue here only happen to X11 clients? Both SSD and CSD or just one of them? Maybe we can just look at the result for META_MOVE_RESIZE_RESULT_FRAME_SHAPE_CHANGED? Or introduce a new enum value and include it in result for the cases that are breaking.
Created attachment 353207 [details] [review] window: Include STATE_CHANGED flag when tiling (In reply to Rui Matos from comment #4) > Did you find out the exact conditions under which we fail to call > sync_window_geometry() ? I thought META_MOVE_RESIZE_STATE_CHANGED would > still catch all the cases that don't change the MetaWindow geometry. Oh, good point - the flag can obviously only catch cases where we include it, which isn't the case for tiling at the moment. So this patch should fix the issue as well (at least as far as I can reproduce it) ...
Review of attachment 353207 [details] [review]: aha, yes that should do it
Attachment 353207 [details] pushed as 4d7329a - window: Include STATE_CHANGED flag when tiling