jrmuizel noticed that we spend quite a bit of time calculating and painting the opacity transition for tabs that are opened and closed. He says that it's probably not worth it for an animation that's really only about 3 frames long. I did a try push where I disabled the opacity transition, and compared it against a baseline UX push: Baseline: https://tbpl.mozilla.org/?tree=Try&rev=8766874949d5 Patch: https://tbpl.mozilla.org/?tree=Try&rev=1479ca62a9ec Compare talos: http://compare-talos.mattn.ca/?oldRevs=8766874949d5&newRev=1479ca62a9ec&server=graphs.mozilla.org&submit=true Compare talos shows us some pretty nice wins across the board - particularly on the close animations. Here's my Baseline UX push compared against m-c: http://compare-talos.mattn.ca/?oldRevs=00bf153a66e4&newRev=8766874949d5&server=graphs.mozilla.org&submit=true and here's the patch push compared against m-c: http://compare-talos.mattn.ca/?oldRevs=00bf153a66e4&newRev=1479ca62a9ec&server=graphs.mozilla.org&submit=true This change could effectively halve the XP regression.

I should note that the opacity transition happens so quickly that there's (at least to my eyes) no perceivable difference in experience when running the patched build. Stephen, do you agree? (link to build: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mconley@mozilla.com-1479ca62a9ec/try-win32/firefox-27.0a1.en-US.win32.zip)

(In reply to Mike Conley (:mconley) from comment #0) > jrmuizel noticed that we spend quite a bit of time calculating and painting > the opacity transition for tabs that are opened and closed. Looking at all the comparisons on XP and others, I'd say that all the tab-close animations have a very meaningful gain from this, while tab-opens either don't gain nothing gain very very little. Are we sure it happens for both tab open and close?

Yes, the opacity animation occurs for both tab open and tab close, but it happens differently for each. For tab open, we wait 20ms before the opacity transition occurs, thus making the tab invisible for the first 20ms of the min-width animation. For tab close, we wait 160ms before the opacity transition occurs, thus hiding the tab for the last 20ms of the min-width animation. I should also note that when a tab closes, unless it's being hovered by the mouse, the tab should be *completely transparent*. This is because when a tab is closed, selection is moved to another tab before the tab-close animation begins, and Australis makes unselected tabs transparent. So really, the only way to see the tab close opacity transition is to hover the mouse over the closed tab. And even then, it's for ~3 frames.

Looks good to me. You are right that the current opacity transition isn't very noticeable anyway.

Landed in UX as https://hg.mozilla.org/projects/ux/rev/c7d52e8d15ff

(In reply to Mike Conley (:mconley) from comment #3) > I should also note that when a tab closes, unless it's being hovered by the > mouse, the tab should be *completely transparent* So, I'm quite sure that TART doesn't hover the tab on close, and since it doesn't render any kind of transparency (or indeed nothing at all as the entire tab just disappears once closed and just the tab-close-button slides into its new place), why could removing transparency affect performance on this case in the first place? This is probably worth a gfx/layers bug on its own.

Here's a screencast of the tab animations on Windows XP, slowed down 10x. http://screencast.com/t/e3xV5Bnyl