remove fade from the compiz plugin list

Fair point. Can that go through the normal Design approval lifecycle please? Affecting ayatana-design first.

 status confirmed

I think this is just a question of Compiz defaults. Please remove the
"fade to anticipated window" feature. Just show the windows, tab through
them, and switch (as close to instantly as we can) on release of Alt.

I don't know how to fix-committed the design task by email, anybody else
know?

I think it's rather a bug, it's confirmed by Paul, lamalex and I. Depending on the apps that are opened, I can get Alt + Tab being very slow (maybe something with thumbnailing?). The fade can be removed as well of course, but I confirm that doesn't explain the delay with the staticswitcher plugin.

Can you confirm that with or without the fade effect (that we can disable):
- open two smalls apps on a ws (like gedit and a terminal) and only them.
- alt tab
- the delay is fine for you?

so, after discussing with paul, it seems there are indeed two issues. The fade-in/fade-out delay and the alt + tab bug tracked as bug #684843.

Let's maybe wait for that one to be fixed so see how fade in/fade out is slow or not?

We've dug into this a bit more, there are several things going on; the three we've specifically itemised so far; this are probably all down to the 'staticswitcher' Compiz applet, so this possibly wants moving there instead of Unity. Items:

  1. Fade-in vs. Fade-out speed as the two windows transition. The Fade-out speed is okay, but the Fade-in speed is too high (> 100 msec)
  2. The latency of the grey chaser rectangle is too laggy. This can be set using CCSM->Window Management->Static Applet Switcher->Behaviour->Speed (this value is inverse, higher is faster). Didrocks reckons that a value of 6.5-7.5 is an improvement and I agree, but there also appears to be some baseline overhead, possibly:
  3. The tabbing latency is dependant upon the complexity of the target backing pixmap. Eg. switching to a HUGE image in eog causes a delay of 2+ seconds. This is now filed as bug #684843.

For (1): the fade-in and fade-out could be made asymmetric: new window appears near instantaneously, old window fades out slowly. If the are completely overlaid the fade-out will be less apparent, but if they are in different areas of the screen it will still be noticeable.

For (2): the speed can be improved by setting a different default value for the moment

For (3): tracking on the other bug report but the resultant infinite swapping could be the root cause of the crashes I'm getting on a 1GB ThinkPad.

Fade-in/out is wrong regardless, please disable it.

Mark

Another related issue: the disparity in latency between very fast Alt-tab keypresses and slower Alt-tab keypresses is now filed as bug #683635.

ok, changing the default set then.

The disparity in latency with respect to key press-and-release speed is bug #684871. In comment #7 above I had managed to link back to /this/ bug report...

Mark, Didier

The fade plugin should not be removed from the plugins list. It handles the opacity transitions for every single plugin, scale, etc.

If the time is too long you should shorten it. But if you remove the plugin entirely you will be wrecking the effect of a lot of other plugins.

Sam, is there a better (eg. numerical) setting that can be adjusted to disable the fade, or to reduce it to under 0.0-0.1 seconds? I suspect the wish here is not to remove core fade functionality completely, but to just disable it by default in the case of staticswitcher.

Because this is marked as Fix Committed I have tried to find the tree which received the commit in order to get a better overview of what was done, but I can't find which one it would have been. Hopefully didrocks can shed light on what got changed/patch for the moment and whether this is the best long-term solution.

Look, surely we can remove the fade effect from alt-TAB without
affecting other pieces of the Compiz experience? If not, that's a bug
that we need to fix.

Regardless:

 - please do not fade between underlying windows during ALt-TAB, the r
esulting noise on the screen is extremely disturbing
 - please be super-fast on the actual "picker", at the moment it's very
delayed there

Mark

On Sun, Dec 5, 2010 at 4:15 PM, Mark Shuttleworth
<email address hidden> wrote:
>
> Look, surely we can remove the fade effect from alt-TAB without
> affecting other pieces of the Compiz experience? If not, that's a bug
> that we need to fix.
>

No it is not possible without a major overhaul of the way that plugin
works. It also requires extensive work in other plugins.

> Regardless:
>
>  - please do not fade between underlying windows during ALt-TAB, the r
> esulting noise on the screen is extremely disturbing

Put animations framework to the top of my work items and then we can
deprecate the fade plugin

>  - please be super-fast on the actual "picker", at the moment it's very
> delayed there

This will need heavy lifting too - currenly we are waiting for the
decorator process to draw our picker window and it is slow. I don't
see any other way to do this other than to completely rewrite these
plugins.

>
> Mark
>
> --
> You received this bug notification because you are a member of Canonical
> Desktop Experience Team, which is subscribed to Unity.
> https://bugs.launchpad.net/bugs/683635
>
> Title:
>  remove fade from the compiz plugin list
>
> Status in Ayatana Design:
>  Fix Released
> Status in Unity:
>  Fix Committed
> Status in “compiz” package in Ubuntu:
>  Fix Committed
>
> Bug description:
>  Alt-Tab between applications under Unity requires a fade that takes longer than 100 milliseconds, placing the action beyond the response limits recommended by the GNOME HIG.
>
> Since I am capable of alt-tabbing at 5+ keypresses per-second (if the LIFO order is predictable - see bug #682973) the fading and alt-tab system needs to give a reliable visual response within the window between subsequent Alt-tab invocations.
>
> If the user is working ahead of the display system intermediate drawing steps should be dropped and only the cumulative state shown to the user.  To reproduce:
>
>  1. Press Alt-tab lots (eg. 20+ times at 5-10 Hz)
>  2. Release over the window of your choice
>
> Expected: that window immediately appears usable within 100 milliseconds
> Actual: Alt-tab pager carries on "catching up" with the user (and since there at multiple windows open this is statistically unlikely to be the window that the user released on).
>
> The many-many-presses is an extreme example but hopefully clearly demonstrates the disconnect between the user's input and the tab pager/fade system.
>
>
>

--
Sam Spilsbury

Err, in the Appearance tab in ccsm for this plugin set the opacity to 100. Is that the fade you wanted to get rid of?

Travis: the stuff that's trying to be toned down/eliminated here is all the stuff that creates a perception of lag or delay in the Alt-tab process and which prevents interactions feeling clickity-click snappy. Based on the last two comments here (#13 and #14), I've tried two things:

  a. CCSM->"Fade"; switching to "Constant Time" (vs. Constant Speed) and seeing Speed to minimum (0.1, no known/documented units). This makes the experience a bit more pleasant but seems to have a bug (I was no longer able to alt-tab back to the CCSM window, like a game of whack-a-mole, other unfocused windows kept being raised instead)
  b. CCSM->"Switcher"; setting opacity to 100%; this means windows are no longer "disappeared". All are shown on the screen during the alt-tab process and just the stack order is changed... this is probably closer to what people are used to, and since everything is already completely opaque (except terminals) there is no appreciable fading.

Both help, but both feel like workarounds.

Didier: I've just noticed the setting just below those "Build Mipmaps for smooth scaling"... I bet this is the root-cause; doing that successful scaling (times N windows onscreen) would account for the massive blip in RAM usage that causes the deadlock/disk I/O death in extreme cases, and in normal cases is just causing the multi-second lag).

On Sun, Dec 5, 2010 at 8:49 PM, Paul Sladen <email address hidden> wrote:
> Travis: the stuff that's trying to be toned down/eliminated here is all
> the stuff that creates a perception of lag or delay in the Alt-tab
> process and which prevents interactions feeling clickity-click snappy.
> Based on the last two comments here (#13 and #14), I've tried two
> things:
>
>  a. CCSM->"Fade"; switching to "Constant Time" (vs. Constant Speed) and seeing Speed to minimum (0.1, no known/documented units).  This makes the experience a bit more pleasant but seems to have a bug (I was no longer able to alt-tab back to the CCSM window, like a game of whack-a-mole, other unfocused windows kept being raised instead)
>  b. CCSM->"Switcher"; setting opacity to 100%;  this means windows are no longer "disappeared".  All are shown on the screen during the alt-tab process and just the stack order is changed... this is probably closer to what people are used to, and since everything is already completely opaque (except terminals) there is no appreciable fading.

Load the fade plugin after the switcher plugin (go ccsm -> preferences
-> plugin list -> allow manual sorting -> move switcher before fade)

>
> Both help, but both feel like workarounds.
>
> Didier: I've just noticed the setting just below those "Build Mipmaps
> for smooth scaling"... I bet this is the root-cause; doing that
> successful scaling (times N windows onscreen) would account for the
> massive blip in RAM usage that causes the deadlock/disk I/O death in
> extreme cases, and in normal cases is just causing the multi-second
> lag).

This happens on the GPU, it should not be slow.

The real problem here is that the decorator is used to draw the
switcher window and we have several round-trips and waiting for it to
appear. This has been in compiz since the beginning of time and I plan
to change it at some point, however it will require extensive work
when I do end up fixing it.

>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in ubuntu.
> https://bugs.launchpad.net/bugs/683635
>
> Title:
>  remove fade from the compiz plugin list
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

@Paul: the fix committed is in the compiz branch as I removed the fade plugin by default.

@Sam: Well, I didn't do that, because as tested and already reported, the first time someone change a setting in ccsm, the order is garbled back to the default. So yeah, as discussed on IRC, I'll add an artificial <deps> so that switcher load before fade to workaround that issue then. reopening the bug and handling it.

fade deprecation and reorgnization is put in bug #685763

So, fade now loads before staticswitcher, the default profile is changed as well as the dependency to avoid ccsm putting it after again.

This bug was fixed in the package compiz - 1:0.9.2.1+glibmainloop3-0ubuntu1

---------------
compiz (1:0.9.2.1+glibmainloop3-0ubuntu1) natty; urgency=low

  * new glibmainloop branch snapshot:
    - fix launching an application set it to the wrong place (LP: #683273)
    - Can't resize windows to be displayed on several monitors (LP: #455378)
    - Scale All Windows gets its suffixes wrong for a 3x3 layout (LP: #683063)
    - Compiz sometimes loses focus when closing some windows (LP: #671459)
    - Fix hanging when session exit (LP: #683121)
  * debian/patches/000_fix_OOo_crash1.patch
    debian/patches/000_fix_OOo_crash2.patch
    debian/patches/001_fix_gconf_path.patch
    debian/patches/003_more_gconf_parser_fix.patch:
   - remove, upstreamed.
  * debian/patches/060_move_checks_to_compiz.patch:
    - adapt to new version
  * debian/patches/01_backport_trunk_fix.patch:
    - backport some additional fixes from trunk, otherwise compiz crash at start
  * debian/source_compiz.py:
    - fix gconf path
  * debian/compiz-gnome.gconf-defaults, debian/rules, debian/unity.ini,
    debian/patches/030_no_fade_in_staticswicher.patch:
    - change order to load fade before staticswichter to avoid the fade effect
      when alt + tabbing (LP: #683635)
    - add snap and workarounds by default as well
  * debian/compiz-gnome.gconf-defaults,
    debian/compiz-keybindings.sed,
    debian/patches/021_hide_tooltip_on_decorator.patch,
    debian/patches/057_update_gnome_bindings.patch:
    - update the gconf path from allscreens to screen0 as new gconf path in the
      gconf backend
  * debian/control:
    - handle the ABI breakage with other compiz components
 -- Didier Roche <email address hidden> Mon, 13 Dec 2010 16:38:10 +0100

Alt-Tab has been removed, at least for my setup...

@Jakub: fade as nothing to do with alt + Tab, can you ensure you are with the unity default? (unity --reset should reset all your compiz configuration)