815354 - Make tab open/close animate at 60fps on amd c-[345]50 devices. In the case of no overflow(ie up to 5 tabs, no tab resizing)

Status: RESOLVED INCOMPLETE

(Firefox :: Tabbed Browser, defect)

Description

[(dormant account)]

We are aiming for best-case performance here. We'll handle edge cases in other bugs.

Comment 1

[Avi Halachmi (:avih)]

Here are some of my observations about current performance:

Tests setup:

"Vanilla" Firefox:
- Firefox 32 nightly binary download, 2012-11-28:
- Auto-update disabled
- Clean profile
- New tab page (browser.newtab.url) set to about:blank

I'm testing on two laptops with Windows 7-x64 while using an Aero theme (with desktop composition):
1. "fast" PC: Intel i7-3630qm (2.4-3.2 GHz) using the embedded GPU - HD4000, 12G ram.
2. "slow" PC: AMD e-350 (0.8 - 1.6 GHz) using the embedded GPU - Radeon 6310, 4G ram.

- Tabs were opened and closed using KB only (CTRL-t, CTRL-w)

Note: performance of non-aero theme or non-windows OS were not yet tested.

Measurements:
1. Using Fraps (3.5.9) to display desktop FPS (watches for changes only, so can get single-digit FPS on idle). Overhead appears to be minimal to non existent.
2. Visually by looking at the animation and assessing the fluidity.

Note 1: Fraps averages the last second, and since tab open/close animation is much shorter, I opened 2-3 tabs, then close them, and repeat this process quickly. This may introduce GC and reduce fluidity and FPS.

Note 2: Proper measurement of the number of frames displayed (and derived FPS) strictly during tab open/close animation is currently not performed (help on this would be appreciated).


Test results:
-------------

Note: Results were not fully consistent. I'm currently guessing that GC and/or other maintenance kick in on some stages and affect performance. The results below are therefore the best results which I could reproduce, without taking into account worse results, per configuration. If some results were more/less consistent, I've noted that.


1. Vanilla Firefox:

Fraps:
- Fast PC: 38 FPS
- Slow PC: 38 FPS

Visually:
- Both PCs seem very similar in performance and fluidity, and both are less than ideal, but not terrible, results are relatively consistent and variance seems small.


2. With layout.frame_rate.precise set to true:

Fraps:
- Fast PC: 55 FPS
- Slow PC: 47 FPS

Visually:
- Both PCs look much better than before.
- The fast PC still not always fully fluid (i.e. occasional "missed frames"), but otherwise quite good.
- The slow PC seems to have bigger variance in fluidity, compared to test 1, and more results were less fluid.
- The slow PC possibly has a relatively consistent missed frame or two at the beginning of the animation.


3. Same as test 2, with layout.frame_rate set to 240:

Fraps:
- Fast PC: 60 FPS
- Slow PC: 47 FPS

Visually:
- Fast PC: very fluid - mostly no noticeable glitches and results are very consistent.
- Slow PC: no noticeable change from test 2.


4. (Slow PC only): same as tests 2/3, with simplified tab graphics, to hopefully increase draw speed:
- Remove the tab close button (browser.tabs.closeButtons -> 2)
- Remove tab throbber and icon (via chrome\browser\skin\classic\aero\browser\browser.css)
- New tab title changed from "New Tab" to empty ("").
- At the same browser.css file: hardcode replace all instances of "background" with "Xbackground" (also replaces background-color etc). This effectively disables all transparency, gradients and background images for the whole browser, including the tabstrip. The browser looks very "flat", and current tab is not highlighted, but the browser is usable.

--> The tab looks 100% flat and empty of any content (no title, no throbber/icon, no gradient, etc).

Fraps:
- Slow PC: 50 FPS.

Visually:
- Slow PC: looks smoother than tests 2/3. Especially the beginning of the animation when opening a tab. Variance is also smaller, and the results seem more consistent.


5. (slow PC only): Tried to remove and restore individual elements (gradients, buttons, throbber, title) to find if any of them contributes to the smoothness more than that others.

Very hard to assess results. I did not find a single change which affected the results dramatically. Obviously, all the results are somewhere between the results of test 3 and test 4, which are quite near to each other to begin with.

Comment 2

[Timothy Nikkel (:tnikkel)]

I wonder how the patch in bug 731974 would affect these numbers.

Comment 3

[Avi Halachmi (:avih)]

I've re-tested with better measurements (no more using fraps, and letting the browser settle between operations), and also added testing with the current patch for bug 731974.

- The quantitative results seem to agree with both fraps and the visual assessments from comment #2, including a possible hiccup at the beginning of tab open animation. results now are very slightly better, probably due to the waits between tab operations.

Tests setup:

Changes compared to the default profile ("Vanilla" mode):
- Service and updates disabled (browser and search engines)
- Navigation bar removed (via options)
- New tab url set to about:blank
- Set to remember last tabs on open
- Browser is resized to minimal height and about 1200 pixels wide.
- Console windows is resized to minimum and minimized.

Testing method:
- The browser opens with 2 empty tabs from last time.
- The following tab sequence is performed using the KB with about 3 seconds delay between action, with the mouse cursor off the browser window:
  - open, open, close, open, close, close.

Tested modes:
- On both the fast PC and the slow PC from comment #2:
  - "Vanilla"
  - "Precise": Vanilla with layout.frame_rate.precese set to true
  - "Vlad's": Vanilla with vlad's patch* for bug 731974 applied
  
* Using pre-released patch: https://hg.mozilla.org/try/raw-rev/635f5bcd9734 , which is identical to "newest version, v1" except WinXP specific stuff and shutdown cleanups.

Measurements:
- Debug prints added (see attachment) which measures:
  - Tab open/close prints at browser/base/content/tabbbrowser.xml (at the beginning of addTab/removeTab and at the end of _handleNewTab/_endRemoveTab)
  - vm->ProcessPendingUpdates(); intervals** at nsRefreshDriver.cpp
  - vm->ProcessPendingUpdates() duration (inside nsRefreshDriver::Notify() ).
  - nsRefreshDriver::Notify() function duration when updates are performed (DoTick() in vlad's patch)

** Intervals are measured using a static variable (shared between nsRefreshDriver instances), however, there's only one instance involved throughout all of the tests, so the results should be valid.

Each line has the following measurements:
<instance-id (this)> <interval-from-last-update> (<update-duration> / <whole-function-duration>)

Here are typical results on the Slow PC, with vlad's patch. See attachments for the full typical results of all configuration, and full sequence results per config.

- Slow PC patched open tab:
OOOOO Opening tab...
8f781a8 3797 ( 7.2 /  9.2)
8f781a8   34 ( 9.5 /  14.1)
8f781a8   31 ( 10.1 /  11.0)
8f781a8   17 ( 8.6 /  9.7)
8f781a8   15 ( 7.6 /  8.6)
8f781a8   15 ( 8.2 /  9.2)
8f781a8   14 ( 7.8 /  8.8)
8f781a8   13 ( 7.0 /  8.1)
8f781a8   15 ( 7.3 /  8.6)
8f781a8   13 ( 7.2 /  8.3)
8f781a8   17 ( 7.4 /  8.4)
8f781a8   17 ( 7.7 /  9.0)
8f781a8   17 ( 7.5 /  8.4)
8f781a8   19 ( 7.2 /  8.4)
Tab opened.

- Slow PC patched close tab:
XXXXX Closing tab...
8f781a8 3721 ( 4.6 /  6.0)
8f781a8   20 ( 6.8 /  12.9)
8f781a8   13 ( 8.7 /  9.7)
8f781a8   14 ( 7.8 /  8.9)
8f781a8   12 ( 7.5 /  8.4)
8f781a8   16 ( 7.0 /  7.9)
8f781a8   14 ( 6.9 /  7.8)
8f781a8   13 ( 7.3 /  8.4)
8f781a8   15 ( 7.4 /  8.2)
8f781a8   17 ( 7.2 /  8.0)
8f781a8   18 ( 7.2 /  8.3)
8f781a8   16 ( 7.2 /  8.1)
8f781a8   18 ( 8.4 /  9.3)
8f781a8   17 ( 8.3 /  9.2)
8f781a8   17 ( 8.1 /  9.6)
8f781a8   16 ( 7.2 /  8.7)
XXXXX Tab closed.

Analysis:
- The timing with vlad's patch greatly improves on previous behavior, but the timing is still not 100% perfect (wishful thinking). 
- It appears that even on the slow PC we're fast enough and are doing 60 FPS, except for one or two frames at the beginning of the animation.
- Opening tabs processings are faster on the fast PC, but closing tab performance seems to be similar.
- On the full sequence results, there appears to be one or two updates after the tab was closed/opened. Probably pending updates.

Comment 4

[Avi Halachmi (:avih)]

Attachment: Test 3 measurements patch

Comment 5

[Avi Halachmi (:avih)]

Attachment: Test 3 typical results

Comment 6

[Avi Halachmi (:avih)]

Attachment: Test 3 results - Fast PC Vanilla

Comment 7

[Avi Halachmi (:avih)]

Attachment: Test 3 results - Fast PC Percise

Comment 8

[Avi Halachmi (:avih)]

Attachment: Test 3 results - Fast PC Patched

Comment 9

[Avi Halachmi (:avih)]

Attachment: Test 3 results - Slow PC Vanilla

Comment 10

[Avi Halachmi (:avih)]

Attachment: Test 3 results - Slow PC Percise

Comment 11

[Avi Halachmi (:avih)]

Attachment: Test 3 results - Slow PC Patched

Comment 12

[Avi Halachmi (:avih)]

Bug 837535 recognizes that 5 different linear gradients are painted on each tab animation frame (2 for the animated tab, 3 for the newtab button), out of which 2 are probably always pattern-cache misses.

Bug 835284 adds raster cache for tiled gradient, possibly also for linear gradients. Preliminary results show almost twice as fast paint times during tab animation when linear gradients are cached as 1px tiles (which also eliminates the pattern cache misses during tab animation).