GNOME Bugzilla – Bug 732857
Improve window manager animations
Last modified: 2014-07-29 13:01:09 UTC
Got the idea from a couple threads on gnome-shell-list, and decided to rip off the competition without shame :) Note: only the first patch is for review, the second one is attached if you want to help me debug it. Btw, I believe the proper fix would be for mutter to animate using the target texture, which has the new borders/widget layout and blends smoothly with the final result. Of course, to do that mutter needs to have a target texture in the first place, which is something mutter has control on only with gtk3. Alternatively, we could punt all animated resizing on the client side...
Created attachment 280072 [details] [review] WindowManager: improve minimize/map/unmap animations Using the parameters from Elementary's Gala, which is generally considered a DE that cares about eye-candy.
Created attachment 280073 [details] [review] WindowManager: improve maximize/unmaximize animations Again using parameters from Elementary OS. Unfortunately the effect is not as pleasant: the texture is stretched and the window contents update suddenly at the end, while the anchor point is often in the wrong place.
I tried the patches. It's certainly interesting. I do feel that our window animations could do with some work. Right now, the animation when opening/closing a window isn't really noticeable. Also, the animations for dialogs opening/closing seem too long. This makes the transition feel clunky. Regarding the changes in the first patch: * Minimize feels like an improvement. * Open window does feel smoother than what we have, but it also feels a bit too severe and in your face * Open menu seems really too much. It's distracting.
(Consider that right now, there is no animation at all for open/close window, except for attached modal dialiogs) For the new open window animation, to me it looks like what most other OSes provide, but I'm open to suggestions. For open menu, I agree the animation is a bit long, and probably should be different (slide+fade like we do for shell menus?)
Review of attachment 280072 [details] [review]: ::: js/ui/windowManager.js @@ +726,3 @@ + _shouldAnimateActor: function(actor, types) { + if (!this._shouldAnimate) Drive-by comment: You stopped calling _shouldAnimate here
(In reply to comment #4) > (Consider that right now, there is no animation at all for open/close window, > except for attached modal dialiogs) > > For the new open window animation, to me it looks like what most other OSes > provide, but I'm open to suggestions. I'd be interested to try what's in the patch, but with a slightly shorter duration. > For open menu, I agree the animation is a bit long, and probably should be > different (slide+fade like we do for shell menus?) Yep, agree. Also, it would be good to preserve the existing dialog window animation, but with a faster transition.
Created attachment 280129 [details] [review] WindowManager: improve minimize/map animations Using the parameters from Elementary's Gala, which is generally considered a DE that cares about eye-candy.
Created attachment 280130 [details] [review] WindowManager: improve maximize/unmaximize animations Again using parameters from Elementary OS. Unfortunately the effect is not as pleasant: the texture is stretched and the window contents update suddenly at the end.
Created attachment 280131 [details] [review] WindowManager: improve destroy window animation The animation is the same for modal dialogs, but it is now run for non modal dialogs too (matching the new behavior on show). In addition, we run a destroy animation for normal windows, if they use CSD (there are technical limitations that prevent running animations after destroy on server decorated windows)
Created attachment 280137 [details] [review] tweak the patch set I've spent a bit of time playing around with these patches, mostly looking at open/close window animations. The attached patch feels like an improvement to me - feel free to fold it into the patch set, if you agree. A couple of points though: * These open/close animations don't really work when the window is maximized. * The maximize/unmaximize animations don't seem to work in general, probably due to GTK+ not handling the resize well. * The animation needs to be quicker when destroying modal dialogs - I've found that 0.10 works well.
Created attachment 281912 [details] [review] WindowManager: improve minimize/map animations Using the parameters from Elementary's Gala, which is generally considered a DE that cares about eye-candy.
Created attachment 281913 [details] [review] WindowManager: improve destroy window animation The animation is the same for modal dialogs, but it is now run for non modal dialogs too (matching the new behavior on show). In addition, we run a destroy animation for normal windows, if they use CSD (there are technical limitations that prevent running animations after destroy on server decorated windows)
Created attachment 281914 [details] [review] WindowManager: update animation timings after designer review Lapo, Jakub and Allan all agree with this.
Review of attachment 281912 [details] [review]: ::: js/ui/windowManager.js @@ +891,3 @@ + }, + + _shouldAnimateNormalActor: function(actor) { Not sure I like this name what is a "normalActor" ? Also you only call it once ... can't you just open code it instead like you do for the "non normal" case ? i.e pass the types to shouldAnimateActor ?
Review of attachment 281913 [details] [review]: OK.
Review of attachment 281914 [details] [review]: OK.
Pushed after addressing review comments. Attachment 281912 [details] pushed as eda27d5 - WindowManager: improve minimize/map animations Attachment 281913 [details] pushed as d4f0b5b - WindowManager: improve destroy window animation Attachment 281914 [details] pushed as aa2fc3c - WindowManager: update animation timings after designer review