1234926 - 3% Win7 tsvgx/tps regression on Mozilla-Inbound on Dec 23, 2015 from push ccc320a19060

Status: RESOLVED WONTFIX

(Core :: Graphics: Layers, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

Talos has detected a Firefox performance regression from your commit ccc320a19060 in bug 1072501.  We need you to address this regression.

This is a list of all known regressions and improvements related to your bug:
http://alertmanager.allizom.org:8080/alerts.html?rev=ccc320a190607b5e39f48e72e0a32314f60820d5&showAll=1

On the page above you can see Talos 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, please see: https://wiki.mozilla.org/Buildbot/Talos/Tests#tps

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 win32 -u none -t g2,svgr  # add "mozharness: --spsProfile" to generate profile data

To run the test locally and do a more in-depth investigation, first set up a local Talos environment:
https://wiki.mozilla.org/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 tps

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 will be backed out! ***

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

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

there are some wins/losses, here are the list of regressions that seem to be valid:
tp5o e10s win7:
https://treeherder.allizom.org/perf.html#/comparesubtest?originalProject=mozilla-inbound&originalRevision=15e06810ae30&newProject=mozilla-inbound&newRevision=ccc320a19060&originalSignature=92bf5647ee18b4288bce380ddc91f1fbf70be212&newSignature=92bf5647ee18b4288bce380ddc91f1fbf70be212

tp5o_scroll win8:
https://treeherder.allizom.org/perf.html#/comparesubtest?originalProject=mozilla-inbound&originalRevision=15e06810ae30&newProject=mozilla-inbound&newRevision=ccc320a19060&originalSignature=f1095a72f5df055d3f330b688f71d370d5b26990&newSignature=f1095a72f5df055d3f330b688f71d370d5b26990

tsvgx win7:
https://treeherder.allizom.org/perf.html#/comparesubtest?originalProject=mozilla-inbound&originalRevision=15e06810ae30&newProject=mozilla-inbound&newRevision=ccc320a19060&originalSignature=10e252613ca692c02415637069fdc71d612830bc&newSignature=10e252613ca692c02415637069fdc71d612830bc


Bas, can you take a look at this and help figure out what is going on here?

Comment 2

[Bas Schouten (:bas.schouten)]

We switched to using GDI for opaque surfaces for e10s. We are already using this for non-e10s and we have to use it for e10s in order to have subpixel AA. Some performance characteristic of the Cairo GDI backend are different, this change simply makes our performance characteristics in this area consistent with non-e10s.