839660 - Using images for gradients in the tab strip is slower than using linear-gradient.

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

We've been trying to better the performance of the new curvy tabs for Australis, and one thing we thought would help was to switch from using linear-gradients for the tab backgrounds to using tiled images to achieve the same gradient effect.

After quite a bit of testing, we actually found paint times using images to be sometimes 1ms slower than using linear-gradients.

Gfx found this surprising.

Here's some more data:

1) The tests we've been running (see https://bugzilla.mozilla.org/show_bug.cgi?id=824845#c7) have been on a low-powered netbook (1.6 Atom, 1GB memory, no hardware graphics acceleration).
2) There was a slow path we were hitting where we flip a portion of the tab across the Y-axis (we only have one curve image, and we just flip it for the other side of the tab). Removing this should have taken us out of the slow-path, but made things even slower on average.

Here's a profile:

http://people.mozilla.com/~bgirard/cleopatra/#report=b5dd32facbc0aebc3654d082b036519c94404369

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Tell me about these images; can you give a link to one of them that you're tiling?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Attachment: Tiled gradient PNG

Sure thing - here's the image.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Attachment: Apply this first (instrumentation and some uglification)

So, I thought I'd help you all recreate the test in case you wanted to try it.

The patches I'm about to post should be applied to the UX branch.

This first patch makes things look pretty ugly - basically, MattN and I were trying a myriad of things to speed up the tab animations, and we did investigations *without* cleaning up the results or making them pixel-perfect. So the end result looks pretty fugly. This is expected.

Beyond that, this patch also preps the test-case, and I'll explain how you can trigger that in a follow-up comment.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Attachment: This patch uses PNGs for the tab background gradients

This patch needs to be applied on top of attachment 713013 [details] [diff] [review] (and both should be applied to the UX branch).

This patch switches the tab backgrounds to use a PNG for the linear gradients instead of the linear-gradient function.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Re: uglification, with both of these patches applied, should look something like this on Windows 7: http://i.imgur.com/3fEGzTl.png

This is expected.

So, to trigger the test-case:

0) Switch to the Windows Classic theme.
1) Create a fresh profile
2) Disable telemetry and addon updates. We've also been testing without hardware acceleration, so you might want to disable that too.
3) Set browser.newtab.url = about:blank
4) Set browser.tabs.animationLogging.enabled = true
5) Hide the navigation toolbar (the location bar repaints every ~500ms)
6) Restart Firefox
7) Wait a few seconds for Firefox to settle down after start-up
8) Open two new blank tabs
9) Hover over each tab, close buttons and new-tab-button to have images loaded
10) Move mouse away from the browser
11) Hit ctrl-W to close a tab - this will initiate the test

What you'll see is a tab close and open 15 times.

Gathering results:

12) Then, open up the Error Console, and look at "Messages".
13) Scroll right to the bottom, and gather the Interval and Paint times for both tab open and tab close (these should be the last two entries)

We've been running steps 7-13 for 4 runs, and then averaging the interval/paint times for our results.

You should test this without the PNG gradient patch, and then with.

The numbers will vary from machine to machine, but here's what I got on my little crappy netbook:

Without PNG gradients
Avg tab-open interval :  58ms        paint:  12ms
Avg tab-close interval:  34.8ms      paint:  7.95ms

With PNG gradients:
Avg tab-open interval :  54.1ms      paint:  12.3ms
Avg tab-close interval:  38.4ms      paint:  8.3ms

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Let me know if there's any more data I can provide.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Stab in the dark - I wonder if this could be related to bug 826422, since our image is a 1 x 29 column of pixels.

I'm going to try with a larger image (240px, which is the current max-width of a tab), and see if that moves the needle any.

Comment 8

[u428464]

(In reply to Mike Conley (:mconley) from comment #7)
> I'm going to try with a larger image (240px, which is the current max-width
> of a tab), and see if that moves the needle any.

Important to note that according to the mockups max-width of an Australis tab will be 180px.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Using a gradient PNG with a width of 180px did not make a significant difference to performance. The averages more or less stayed the same.

Comment 10

[Avi Halachmi (:avih)]

(In reply to Mike Conley (:mconley) from comment #7)
> Stab in the dark - I wonder if this could be related to bug 826422, since
> our image is a 1 x 29 column of pixels.

It's not directly related to this issue wince that's not gradient tiling, but rather image tiling, and these are different parts of the code.

But regardless, there could be a difference between a tiling 1px image over 180px to resizing one big image (or just masking it).

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Making it 180x29 and having that make no difference is very surprising to me!  Try 32x29 maybe?

Comment 12

[u428464]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #11)
> Making it 180x29

180x28

Comment 13

[Mike Conley (:mconley) (:⚙️)]

I just tested with a PNG with a width of 32. No significant difference.

It doesn't seem to matter if the width is 1, 32, or 180.

And in all cases, the images perform poorer than linear-gradient.

Comment 14

[Avi Halachmi (:avih)]

Maybe this is a result of the test system not using D2D (anymore?)?

When D2D is enabled, gradient painting is suboptimal, especially for the tab animation case which suffers from many cache misses (bug 838758 should improve the cache misses). I'm guessing that prior cases where PNGs were faster were tested with HW acceleration enabled in Firefox.

It's also possible that the same test system used D2D in the past, but now doesn't due to recent blacklisting, as is the case with AMD E-350 (and its igpu 6310).

Comment 15

[Avi Halachmi (:avih)]

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).

Comment 16

[Jared Wein [:jaws] (please needinfo? me)]

What's the plan for this bug? Is it worth keeping around?

Comment 17

[Avi Halachmi (:avih)]

Now that we have a useable TART, is this still the case that images are slower than gradients?

Comment 18

[Mike Conley (:mconley) (:⚙️)]

I think we should re-measure with TART and (a) verify. If we can verify, it might be worth seeing if (b) there's an easy win we can get from Graphics here, and lean on it.

If not (a) or (b), we should bail.

Comment 19

[Jared Wein [:jaws] (please needinfo? me)]

Assigning to Mike based on conversation over IRC.

<mconley> jaws: a thing I wanted to try but didn't get around to yet was altering the background gradient PNG to be larger. We had 6 pixels wide before. 32 might be better

Comment 20

[Mike Conley (:mconley) (:⚙️)]

So I don't think this bug is valid anymore - we're moving the gradients into the stroke image, and that's shown to be faster in bug 921038 (see comment 10).