Window management - window animations are too fast for some people to see.

I suspect there are fixes that could be made to the zoom animation to make it more visible than it is at present.

Though, I do agree with slower animations. In upstream compiz, we use slower animations that are easy to see, and more visually pleasing. It's mainly only downstream in ubuntu where some animations have been made too fast to see.

I disagree completely with varying the animation speed over time. That kind of inconsistency will really annoy people.

Also note: The number of frames of the animation you see is directly linked to the rendering performance. The better graphics performance you have, the more frames you will see. Because it's the duration of the animation that's fixed, and not the number of frames (hence visibility).

We are working to dramatically improve graphics performance of compiz and unity, which will make more animation frames visible in the first place.

@vanvugt; the idea behind the having a slower animation to start with and then increasing in speed during usage is to solve the tradeoff between "slow clear animation allows the user to see exactly what is happening, but makes the computer feel slow and is annoying with repeated usage" and "fast snappy animation makes the interface feel quick and gets out of the way of the user, but is not so descriptive".

Once a user has learnt that minimised windows live in the Launcher, the best animation is something super snappy, exactly like we have at the moment. We don't want this to change. However to solve the 'new user using Ubuntu for the first time ever' use case, an initial slower animation that gets slightly quicker everytime a window is minimised should do the trick. Yes this approach has the animation speed change over time without explaining this to the user, but at most the perceived effect will be the computer getting quicker, and in most cases won't be noticed because minimise animations are the type of thing that are not consciously watched after seeing them happen for the first few times. This way we are teaching the user about how Unity behaves, and then getting out of their way with the minimum of fuss.

This will also need to be tested, so it would be much appreciated if you could expose 'starting speed', 'speed decline duration in number of minimises' and 'ending speed' variables (as well as a 'reset' option for testing purposes), and then we can experiment with tuning these variables.

Thanks,
John

@vanvugt; BTW, looking forward to the dramatically improved graphics performance ;-)

John,

If a minimize animation is too fast to show you where in the launcher the window has minimized to, then that's a problem for all users, not just beginners. In that case, increasing the speed of animations is a terrible idea. Because even very experienced users need to be able to see _where_ in the launcher the window minimized to. If the animation speeds up to the point where you can't see where it's going then it will be useless to any kind of user.

We just need to choose an animation that is either more visible by design, or configured a bit slower. I recommend Magic Lamp which is the default minimize animation in upstream compiz. Its visibility is far superior to zoom. Though it needs improvement to look right with vertical docks like the launcher (bug 989463).

@vanvugt; this is something we can easily user test to find the optimum value ;-) If you could expose the three variables I have added to the bug report, plus a 'Magic Lamp/Existing transition' toggle, I'll set up user testing with Charline to try measure the response to different values, and also the response to 'Magic Lamp' versus 'Existing transition'.

This is a great problem to apply user testing to in order to make an objective, as opposed to subjective, decision.

Difficulty: Easy
Method: In UnityWindow::windowNotify (CompWindowNotify n) track the number of times CompWindowNotifyMinimize comes in -> save it to a GSettings key, once it surpasses a certain number, you can change the option in the plugin like this:

CompPlugin *p = screen->findPlugin ("animation");

if (p)
{
     CompOption::Vector &options = p->vTable->getOptions ();

     foreach (CompOption &o, options)
     {
        if (o.name () == "minimize_animations" )
        .... (scan list for first minimize animation for "normal" windows and change the value to something slower.

Update: Unity 6.4 is revision 2632, so this is actually fix committed for Unity 6.6.

Invalid for compiz. The fix for this seems done in Unity.

Though compiz bug 1004251 released in 0.9.8.0 would have helped a lot.

This bug was fixed in the package unity - 6.6.0-0ubuntu1

---------------
unity (6.6.0-0ubuntu1) quantal-proposed; urgency=low

  * New upstream release.
    - Fixes non-escaped character sequences in dash previews (LP: #1039020)
    - Updated background layer for preview cover-art and details panels
      to be 10% low-light
    - Expand a PlacesGroup if it is the only category that contains results
      (LP: #950710)
    - Update unity autopilot tests to match autopilot API
    - Updated the convert files to fix some typos in the key names
    - Add gmodule dependency
    - Activate proper result if the categories aren't displayed in-order
      (LP: #1040101)
    - Refactor device launcher icons (LP: #713423)
    - LauncherController: make the controller enable the launcher struts,
      based on hide-mode option (LP: #1044005)
    - Launcher: make always possible to drag an icon to the bottom or top
      of its sub list (LP: #1043968)
    - Don't desat bfb/hud icon in DNDReset (LP: #1043963)
    - Progressively adjust the speed of the minimize animation. First
      time it is used is slower, then speeds up the more it is used.
      (LP: #1017510)
    - Implement new ordering of categories for home lens. (LP: #1043915)
    - UnityWindow now implements ScaleWindowInterface (LP: #876017)
    - Launcher: restore an icon position after that the dragging has been
      cancelled (LP: #955561)
    - LauncherDragWindow: cancel drag on window mapped/unmapped
      (LP: #1044723)
    - Now there is a check of an override color in RefreshColor (which is
      called when a PropertyNotify event happens). Also added a check in
      FullySaturateColor to a void division by zero. (LP: #975350)
    - Queue redraw after cover-art texture is updated from a url/file source.
      (LP: #1043947)
    - Fixed ability to delete glib::Source wrapper during its callback
      (LP: #1044823)
    - Close preview when dash is hidden. (LP: #1045298)
    - LauncherModel: rewrite the Reordering functions to keep the icon
      priority deltas (LP: #761155)
    - Make sure we can pass extra hints when activating preview actions.
      (LP: #1046352)
    - UnityWindow: scale window code improved (LP: #1033935)
    - The mouse will now cause the HUD buttons to change selection
      (LP: #1042692)
    - "Alt+Space" shortcut to reveal the window menu is not hardcoded, but a
       Compiz key option. " (Hold)" should also be translated. Made all
       Compiz plug-in names and all Compiz plug-in option names in
       unityshell.cpp static constants.
    - remove unity --reset, it's not anymore really needed now that we are
      in stable days of unity and we moved to gsettings
    - Removed the variables 'oldPrev' and 'oldNext' which got assigned the
      value NULL, but then were never used
    - Fixed the size of the previews to 770x380 pixels. (LP: #1045243)
    - UnityWindow: use smart pointers, use static close_icon (with dynamic
      state) and PanelStyle context (LP: #1033935) (LP: #1045127)
      (LP: #1046124) (LP: #1046126)
    - Remove everything in the #ifndef USE_MODERN_COMPIZ_GL ifdefs and remove
      the ifdefs alltogether. unity now requires compiz...