GNOME Bugzilla – Bug 617827
Mis-positioning of a single small window
Last modified: 2013-08-27 00:20:40 UTC
If you have a single window on a workspace, small enough that it doesn't need to be scaled down, it's supposed to be: Centered Pixel aligned But instead it is: Towards the bottom Fuzzy This is a regression that occurred maybe a month or two ago. I've been keeping on meaning to look at this, but never finding the time, so maybe if I file it here someone else will track it down for me. :-)
If it helps, I think I first noticed this around the time we started aligning multiple windows by the bottoms.
Created attachment 160629 [details] [review] [overview] Fix positioning of single small windows A single window that does not need to be scaled down, should be centered and not placed at the bottom. To avoid blurryness window positions should be pixel aligned.
Created attachment 160635 [details] [review] [overview] Fix positioning of single small windows Fix a small bug and don't calculate y twice.
Review of attachment 160635 [details] [review]: Looks good.
Attachment 160635 [details] pushed as 0e9c47b - [overview] Fix positioning of single small windows
The centering is better now, but the pixel alignment isn't. Using floor() doesn't give pixel alignment if: A) The parent isn't pixel aligned (it isn't for me) B) The parent has a scale on it Basic technique (we may have other examples - we did in the past) is to do something like: target_x = (round(target_parent_x + target_parent_scale * target_x) - target_parent_x) / target_parent_scale; That is, convert to screen coordinates, round, then convert back. Where by "target_" I meant "after animation" which might be different from parent.x or parent.scale_x
Created attachment 160815 [details] [review] [overview] Pixel align window previous Unscaled windows should not be fuzzy in the overview, a previous attempt to fix this only integer aligned the clones inside workspace which wasn't enough to fix the issue. Fix it correctly by aligning the absolute rather than the relative position coords.
Created attachment 160816 [details] [review] Pixel align window previews Unscaled windows should not be fuzzy in the overview, a previous attempt to fix this only integer aligned the clones inside workspace which wasn't enough to fix the issue. Fix it correctly by aligning the absolute rather than the relative position coords. (Fixed subject)
Review of attachment 160816 [details] [review]: ::: js/ui/workspace.js @@ +1131,3 @@ + */ + * of the parent. + /* We add a slight delay to be able to get the final positions Rather than adding 0.05, can we do a Meta.later_add(Meta.LaterType.BEFORE_REDRAW) in the onComplete?
(In reply to comment #9) > Review of attachment 160816 [details] [review]: > > ::: js/ui/workspace.js > @@ +1131,3 @@ > + */ > + * of the parent. > + /* We add a slight delay to be able to get > the final positions > > Rather than adding 0.05, can we do a > Meta.later_add(Meta.LaterType.BEFORE_REDRAW) in the onComplete? No, tried it and it does not work (well we do want to call it _after_ the animation of the workspace so BEFORE_REDRAW does not really make sense).
(In reply to comment #10) > > No, tried it and it does not work (well we do want to call it _after_ the > animation of the workspace so BEFORE_REDRAW does not really make sense). Isn't onComplete() called after the animation is done? Oh...I see, our tweener.js uses g_idle_add for onComplete, so a Meta.later_add() queued from there might potentially happen before the idle for a different onComplete() fires. I'm not seeing an immediate elegant solution, so feel free to commit.
My basic opinion is that this patch misses what I was getting at above - that instead tweening to unaligned coordinates and then fixing up after we stop tweening, we want to pixel align the coordinates that we tween to. This does mean that we have to know how things are positioned in the end - we can't simply rely the *current* values of .x/.y/.scale for actors.
(In reply to comment #11) > Isn't onComplete() called after the animation is done? Oh...I see, our > tweener.js uses g_idle_add for onComplete, so a Meta.later_add() queued from > there might potentially happen before the idle for a different onComplete() > fires. The idle is for delegate.onAnimationComplete (which we're apparently not even using for anything any more), not for the onComplete specified in the tweening params. The problem (which we've run into before) is that the end of the animation ends up looking like this: move clone to almost-final scale and position move workspace to almost-final scale and position move clone to final scale and position run clone's onComplete move workspace to final scale and position position run workspace's onComplete so the clone ends up pixel-aligned to the workspace's almost-final position instead of its final position. We'd talked before about making tweener smarter about ordering...
Old bug. We always scale down thumbnails in the overview now, so maybe it has been fixed. Closing as obsolete. Please reopen if you think it's relevant still.