See existing discussions in bug 738491 comment 76 and bug 738491 comment 79. Tab open and close profiling instructions are at bug 824845 comment 7. This bug will be for investigations. Patches to improve performance should be handled in dependencies.

See also: Bug 837535 - tabs and newtab-button paint more than one gradient. Since currently gradients are expensive, we might be able to reduce the number of gradients which should be rendered on each animation frame. Bug 837542 - tab animation uses a lot of pattern-cache memory. This is caused by many cache misses when animating tabs (due to changing tab size which creates a new cache key, and probably unrelated to calc(..) in tab-size). Cache misses are also expensive in performance since we have to re-generate the gradient pattern if we can't reuse an existing one. MattN suggested to use 1px tiles for the background gradients as a solution for the cache misses. Need to verify that it speeds up paints. Bug 835284 tries to cache gradient tiles. Patch V1 Part 2 is a bit hacky, but it caches linear gradients as 1px tiles. This seems to eliminate the cache misses during tab animation, and results in almost half of the original paint time per animation frame. Not sure yet how much of this win relates to the cached tiles, and how much of it to the elimination of cache misses.

(In reply to Avi Halachmi (:avih) from comment #1) > Bug 837542 - tab animation uses a lot of pattern-cache memory. >... > MattN suggested to use 1px tiles for the background gradients as a solution for > the cache misses. Need to verify that it speeds up paints. I just tried it on the UX branch (patch: http://mattn.pastebin.mozilla.org/2114648 ). I can confirm it eliminates the cache misses during tab animation, and also eliminates the resulting memory spike. However, paint performance seem to stay the same. > Bug 835284 tries to cache gradient tiles. ... > Not sure yet how much of this win relates to the cached tiles, and how much > of it to the elimination of cache misses. Right now, it seems that the cached 1px tiles bring the speedup.

Suggested tab animation performance test: Setup: - Have the tab-animation-repeat patch applied - Have a clean profile - Hidden navigation bar - Have 3 tabs open and the browser wide enough to have space left at the tabstrip for another tab - Create (bool) and set browser.tabs.animationLogging.enabled = true - Create (int) and set browser.tabs.animationLogging.repeatCount = 15 "sequence": - Open a new tab using the KB - Move the mouse away from the browser - Close the last tab - Wait for 15 times tab close/open - Write down the avereges of 15 animations for open/close To get the following results: - Start the browser, wait 10s (there's some layer manager swap 5s after browser startup) - Few (~5) "warm up" runs of "sequence" without closing the browser, with few seconds between runs. - Few more (~5) runs (still without closing the browser), write down average paint time to which it converges (for both tab open and tab close) This above procedure was executed on m-c and the ux branches from today, with and without the cache-key patch (from bug 838758). Average paint times results (in ms) (on windows 7 x64, non-transparent Aero theme, i7-3630qm, HD4000) ------------------------------------- m-c open: 3.5 close: 3.3 m-c cache-key open: 2.6 close: 2.4 ux open: 7.3 close: 5.2 ux cache-key open: 6.9 close: 5.3

Bug 838758 comment #15 adds measurements with the same builds on AMD E450 and Intel Atom N450 (D2D is disabled by default on those platforms, which generally makes tab animation faster).

There's another possible reason for bad tab animation performance (regardless of australis, but will probably affect the average frame intervals which we measure here): timing skew caused by the timer filter. See bug 590422 comment #21 and 22.

The investigations have been completed, and the last TART blocker has been lifted. We're not blocking on this tab stuff anymore.

Outdated?