Closed Bug 1524509 Opened 10 months ago Closed 10 months ago

6.33 - 14.01% raptor-motionmark-animometer-firefox (linux64-qr, windows10-64-qr) regression on push 300c5aac4b2e6079dbbe74a4195d5730279c4ceb (Thu Jan 31 2019)

Categories

(Core :: Graphics: WebRender, defect)

Unspecified
All
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla67
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- unaffected
firefox67 --- fixed

People

(Reporter: igoldan, Assigned: lsalzman)

References

(Blocks 1 open bug)

Details

(Keywords: perf, regression)

Attachments

(1 file)

Raptor has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a0f4d41a08cc891d4c58afe9386c146cd9008152&tochange=300c5aac4b2e6079dbbe74a4195d5730279c4ceb

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

14% raptor-motionmark-animometer-firefox linux64-qr opt 48.57 -> 41.76
6% raptor-motionmark-animometer-firefox windows10-64-qr opt 41.85 -> 39.20

You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=19096

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 Raptor jobs in a pushlog format.

To learn more about the regressing test(s) or reproducing them, please see: https://wiki.mozilla.org/Performance_sheriffing/Raptor

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/Performance_sheriffing/Talos/RegressionBugsHandling

Component: General → Graphics: WebRender
Product: Testing → Core
Flags: needinfo?(lsalzman)

Okay, I will look into it to see what is going on here.

Flags: needinfo?(lsalzman)

After talking with Jeff Muizelaar, it was discovered that the real culprit here is blob rendering. Because we are no longer flagging the stacking context as animated, it is creating transforms with different translations/residual offsets every frame, which causes the blobs to get invalidated and re-rendered more.

I've identified a reasonable enough way to fix this and will have a patch ready soon.

This goes back to using IsStyleMaybeAnimated to track whether a SC is animated (which would otherwise be used to determine if a layer is active). Then adds a new parameter to StackingContextParams that separately specifies whether we need to rasterize locally, which again tries to match how FLB manages subpixel AA. This should get rid of the frequent invalidation of blobs. Put in some helpful-ish comments as well trying to explain the mess.

Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #9041531 - Flags: review?(jmuizelaar)
Attachment #9041531 - Flags: review?(jmuizelaar) → review+
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9445d6d53657
track whether a WR stacking context is animated separately from whether it should rasterize locally. r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

I confirm this got fixed:

== Change summary for alert #19248 (as of Fri, 08 Feb 2019 09:00:07 GMT) ==

Improvements:

16% raptor-motionmark-animometer-firefox linux64-qr opt 41.69 -> 48.53
5% raptor-motionmark-animometer-firefox windows10-64-qr opt 39.27 -> 41.40

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=19248

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.