GNOME Bugzilla – Bug 693922
MetaWindowActor: Freeze shouldn't affect actor position
Last modified: 2013-02-16 02:48:47 UTC
If a window is frozen because it is repainting, that shouldn't kee[p us from updating its position: we don't want a slow-to-update window to move around the screen chunkily when dragged. (This does reduce the efficiency of begin/end frames for replacing double-buffering, but that never works very well in the case where there was an overlapping window or the entire screen needed redrawing for whatever reason.) This fixes a bug where a window that was mapped frozen would not get positioned properly until after the map effect finished, and would jump from 0,0 at that point. Since effects *do* need to prevent actor repositioning by Mutter, we must position the actor before any effect starts. Because we now are queuing invalidates on frozen windows, fix the logic for that so that we properly update everything when the window unfreezes.
Created attachment 236306 [details] [review] MetaWindowActor: Freeze shouldn't affect actor position
Review of attachment 236306 [details] [review]: OK.
Attachment 236306 [details] pushed as 3d337a9 - MetaWindowActor: Freeze shouldn't affect actor position
*** Bug 693853 has been marked as a duplicate of this bug. ***
Created attachment 236331 [details] [review] MetaWindowActor: Go back to freezing affecting actor geometry It turns out that the last patch was wrong - it broke some of the most dramatic demos of frame synchronization, like resizing a window from the left and having that be as smooth as resizing from the right. Here's a patch that just excludes the initial map from the freeze, but leaves other geometry changes affected by freezing.
Review of attachment 236331 [details] [review]: This makes sense to me.
For posterity, from IRC: <Jasper> owen, perhaps in the future we should refine the semantics so that map effects will need to set a position <owen> Jasper: possible, yes. This seems rather hacky - and it is there basically because we are allowing the effect *either* to affect the position or not and we dont' know which <owen> I believe you see a bad effect from this in gtk+/tests/animated-resizing - where it jumps about to begin with - the position is frozen during the map effect though the map effect just wants to affect the opacity. Then when the effect ends the window starts doing the proper centered resizing <Jasper> owen, I think we should split it out so that there's two freezes -- animation / plugin freeze, and sync freeze <Jasper> And a plugin would have to call freeze_position() or freeze_size(). <owen> OK, it helps if the plugin actually has to do the freeze itself <owen> Maybe something to do when we get rid of the plugin class in favor of something more flexible and library-like <owen> I want to land this patch for now to get things working 95%
Attachment 236331 [details] pushed as d900d83 - MetaWindowActor: Go back to freezing affecting actor geometry