Mason, could you take a look at this? I did some retriggers in the area and it looks like your patch is the culprit. From what data I've gathered so far, this appears to only happen on linux64 non-e10s, so I guess you might question how important this is... https://treeherder.allizom.org/perf.html#/graphs?series=[mozilla-inbound,4c4dfc86eefd577ec8f1a280c4b08d3f6f0f108a,1]&series=[mozilla-inbound,6764e9b1ce6291a6d9683810b584f1f3536362e6,1]&series=[mozilla-inbound,9762e35db1360d056dedab42265a11812c0e111c,1]&series=[mozilla-inbound,0a6714ee3af67c7918a730968318fe7d09d9f8fe,1]&highlightedRevisions=266e1a6642b1&zoom=1455647386355.0166,1455744262506.064,2.1623181329257246,10 -- Talos has detected a Firefox performance regression from push 266e1a6642b1. 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: https://treeherder.allizom.org/perf.html#/alerts?id=173 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: https://wiki.mozilla.org/Buildbot/Talos/Tests#tp5o_scroll 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 g1 --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: https://wiki.mozilla.lorg/Buildbot/Talos/Running#Running_locally_-_Source_Code Then run the following command from the directory where you set up Talos: talos --develop -e <path>/firefox -a tp5o_scroll (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: https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling

Did some perfherder runs: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=4a027b6a8ffb&newProject=try&newRevision=f5eb1e56bfe3&framework=1&showOnlyImportant=0&showOnlyConfident=1 The regression comes from memsetting allocated memory here - http://mxr.mozilla.org/mozilla-central/source/widget/nsShmImage.cpp#102 I'm not sure what we can do here. The memsetting has to happen because nsShmImage allocates some memory and directly allocates a draw target with the data instead of going the route of TextureClient::CreateTextureForDrawing. We need to memset the memory here for correctness when Skia content lands for Linux. I think we have to accept this regression. Is that ok?

Mason, thanks for digging into this and finding the cause. lets accept this and move forward!