All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=622725

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgoqCXtgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwtqutwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwvW2oAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwpObowoM


Bot(s) for this bug's original alert(s):

linux-release

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mustaq, can you follow up on this?

From the instructions (https://chromium.googlesource.com/chromium/src/+/master/tools/perf/docs/perf_regression_sheriffing.md):
"After your shift, please try to follow up on the bugs you filed weekly. Kick off new bisects if the previous ones failed, and if the bisect picks a likely culprit follow up to ensure the CL author addresses the problem. If you are certain that a specific CL caused a performance regression, and the author does not have an immediate plan to address the problem, please revert the CL."

Kicked off another bisect. The original ones failed silently.

Practical range for this is 401406-401408. Only one change there touches cc and it's 2e7928680f0af8a1d5486499f41c58124b95f601. wkorman, can you investigate.

My change only affects a fake used in tests. We now use an alpha rather than two separate rects to force a fake raster source to be considered non-solid-color. The alpha must be more expensive.

If my change is in fact the culprit then AFAIK we should rebaseline and consider these the new normal. But I realize the perf graph is markedly different, from 30K runs/s to 2.5K runs/s so we should make sure the new world is still ok re: testing what that test is aiming to test.

https://chromeperf.appspot.com/report?sid=2e80a90590a63b410f79e1b2deb353d584ef9ae071457851034a08a65a5eec04&rev=401435

+vmpstr@ for his input.

I'll take a look to see why there is such a significant impact. Off the top of my head, there shouldn't be much difference between the two ways we specify that the raster source is not solid. That is unless one of the approaches erroneously was being detected as solid.

The change here is indeed only to the tests, so generally I would agree with wkorman that this is likely a WontFix, but I'll update when I have a better understanding of what's going on. 

This was indeed an issue with the test that wkorman fixed. The problem was that previously, the tiles were detected as solid and as a result, we ended up marking them solid on the first run and subsequent runs were lighting fast since no more tiles needed to be processed. This was not the intent of the test.