GNOME Bugzilla – Bug 591123
When fading in window icons, use the final position not current position
Last modified: 2009-08-10 14:02:31 UTC
This fixes the problem where when entering the overlay the icons overlayed on the windows could be left in the wrong positions. The problem, as I understand it is: Tweener finishes the window-positioning animation and calls onComplete Tweener then finishes the workspace-positioning animation While these occur at at the same step, the first occurs before the second so the use of actor.get_transformed_position() doesn't work out. The patch simply does some manual positioning calculations instead. An alternate way of handling it would be to wait until Tweener had finished everything before doing the fade in, but that could get tricky. (We were doing something like that earlier and it was tricky.) The problem can be easily triggered in Xephyr with no hardware accel because the animation steps are huge, but I was seeing it happen occasionally in --replace mode with hardware accel as well. (And probably it often happens with hardware accel that the icons are just slightly off.)
Created attachment 140179 [details] [review] When fading in window icons, use the final position not current position The onComplete when positioning windows may come before the final stage of the workspace positioning animation. So we can't use actor.get_transformed_position() to figure out where to put the icons. Compute the final position manually ourselves instead.
Could we trigger the fade in when the animations for the workspaces are complete instead?
Oh, I see but we'd still have the same problem, just in reverse. Maybe have the window animations emit a signal 'complete', then the workspace adds those up, and when the number of completed signals == number of windows, it emits 'complete'. Then the Workspaces does the same thing, just s/windows/workspaces/, and when it gets complete it triggers the window positioning. More complex but it seems like it'd be more robust against any layout changes we may make in the future.
That's what I menat be "An alternate way of handling it would be to wait until Tweener had finished everything before doing the fade in, but that could get tricky. (We were doing something like that earlier and it was tricky.)" Might work to just move starting the fade in animation to an idle - in fact, if we used onAnimationComplete rather than onCompletion then our tweener.js wrapper would do that for us. (IIRC, doing it at idle will cause a frame rate stutter when there's no sync to vblank, since the frame-rate limiting code gets reset when the last animation, but that's probably a clutter bug.) Still, doing it this way seemed like "isolated evil" - not a lot of code and if we change the way the hierarchy for workspaces is set up then icons will be in the wrong place, and we'll look at the icon positioning code and see why.
If doing it in an idle, don't forget to un-queue the idle if we reverse the overlay transition in the middle. Anyways up to you, I'm OK with this patch, just wanted to explore alternatives more.
Going to go with the current patch because it's written and tested, and it's not that much uglier than the alternatives. :-) Pushed.