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)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox65 | --- | unaffected |
| firefox66 | --- | unaffected |
| firefox67 | --- | fixed |
People
(Reporter: igoldan, Assigned: lsalzman)
References
Details
(Keywords: perf, regression)
Attachments
(1 file)
Raptor has detected a Firefox performance regression from push:
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
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 1•5 years ago
|
||
These are the Gecko profiles for motionmark-animometer on Windows 10 Quantum Render (OPT builds):
For motionmark-animometer on Linux 64bit Quantum Render (OPT builds):
|
Assignee | |
Comment 2•5 years ago
|
||
Okay, I will look into it to see what is going on here.
|
|
Assignee | |
Comment 3•5 years ago
|
||
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.
|
|
Assignee | |
Comment 4•5 years ago
|
||
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.
|
||
Updated•5 years ago
|
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
|
||
Comment 6•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 7•5 years ago
|
||
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
|
|
Reporter | |
Updated•5 years ago
|
Description
•