Closed Bug 1259621 Opened 4 years ago Closed 4 years ago

8.21 - 8.21% tcanvasmark (linux64) regression on mozilla-inbound for push 180f3f0494a7 (Wed Mar 23 2016)


(Core :: Graphics, defect)

48 Branch
Not set



Tracking Status
firefox48 --- fixed


(Reporter: jmaher, Assigned: lsalzman)



(Keywords: perf, regression, Whiteboard: [talos_regression] [gfx-noted])


(1 file)

Talos has detected a Firefox performance regression from push 180f3f0494a7. As author of one of the patches included in that push, we need your help to address this regression.

This is a list of all known regressions and improvements related to the push:

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see:

Reproducing and debugging the regression:
If you would like to re-run this Talos test on a potential fix, use try with the following syntax:

try: -b o -p linux64 -u none -t chromez,chromez-e10s --rebuild 5  # add "mozharness: --spsProfile" to generate profile data

(we suggest --rebuild 5 to be more confident in the results)

To run the test locally and do a more in-depth investigation, first set up a local Talos environment:

Then run the following command from the directory where you set up Talos:
talos --develop -e [path]/firefox -a tcanvasmark

(add --e10s to run tests in e10s mode)

Making a decision:
As the patch author we need your feedback to help us handle this regression.
*** Please let us know your plans by Monday, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:
Component: Untriaged → Graphics
Product: Firefox → Core
:lsalzman, I see you landed this and did actually look for talos regressions.  In fact, on opt there are no real regressions, but on PGO we do have this tcanvasmark regression.

Here are the subtests of canvasmark:

I don't know if there is something to do here- can you take a look at this and see what is possible and help make a decision to accept this or work on it.
Flags: needinfo?(lsalzman)
Assigning for decision making, rather than necessarily "getting rid of regression".
Assignee: nobody → lsalzman
Before we were duplicating what Skia's SkDropShadowImageFilter was doing, which is to first blur the RGBA source, then use a Src-In composite operator to use the blurred image's alpha for blending with the shadow color.

While this is good for performance in SkiaGL, it forces us to waste a lot of CPU power blurring the RGB channels of an RGBA image when we only need the A channel to use a mask with the shadow color.

Plus, we have SSE2-optimized AlphaBoxBlur implementation already in moz2d for just this situation.

So this code detects if we're using a software draw target, and if so defaults to a path that extracts the alpha from the source bitmap, uses AlphaBoxBlur on it, and uses the result to mask our shadow color.

The end result is we're now doing way faster on canvasmark since that was what was tanking our performance before:

Overall seems like a happy outcome.
Flags: needinfo?(lsalzman)
Attachment #8735007 - Flags: review?(mchang)
Whiteboard: [talos_regression] → [talos_regression] [gfx-noted]
Attachment #8735007 - Flags: review?(mchang) → review+
Try run:

Looks like even Win7 canvasmark might have boosted up 1000 points from this. Hope it sticks.
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
See Also: → 1266106
Depends on: 1266106
Version: unspecified → 48 Branch
You need to log in before you can comment on or make changes to this bug.