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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=3ac7269932839f1aa5db6ec3db4cb270070f294869e06f0ab53d38fb1f26232d


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

Android Nexus5 Perf
Android Nexus5X WebView Perf
Android Nexus6 WebView Perf
android-nexus5x-perf

blink_perf.layout - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

blink_perf.svg - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

rendering.mobile - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

rasterize_and_record_micro.top_25 - Benchmark documentation link:
  None

loading.mobile - Benchmark documentation link:
  https://bit.ly/loading-benchmarks

blink_perf.paint - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/163f4a57640000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/163f4a57640000

Use vpython and remove vendored pymock. by jbudorick@chromium.org
https://chromium.googlesource.com/catapult/+/23c67a511280f6dbc2a2bea849dd7eed5104809e
51.14 → No values

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  None

CL in question was reverted.

jbudorick: This issue has not recovered.  Please don't just close alert issues with large regressions without checking that they recovered.

chrishtr: Was there anything Paint related in this range that could have changed raster times?  It looks like paint op counts changed, and some page raster times are significantly up.

I think the most likely is this:


https://chromium.googlesource.com/chromium/src/+/de46e4da83ac65a2f1979935460ed05ef8a1a04d

(re-enable zoom for dsf)

Also correlates with all regressions being on Android.

Ahh, since normal raster thread times didn't regress, does it mean the rasterize_and_record benchmark code may be missing the scale factor?

I don't think it should be missed, because zoom for dsf hides the device scale factor in
Blink instead of doing it in cc.

Thee rasterize_time tests doesn't have zoom factor applied. This is same as  issue 871372 . I have confirmed with vmpstr@ that this is expected.

the nested-percent-height-tables regression is due to table element doesn't have sup-pixel support yet. (issue 871387) I checked with eae@ and dgrogan@, and we agree this issue can be ignore for now.

> Thee rasterize_time tests doesn't have zoom factor applied. This is same as
>  issue 871372  . I have confirmed with vmpstr@ that this is expected.

Wait, shouldn't we apply it?  Why WontFix?

The test passes gfx::AxisTransform2d()[1], which means hard coded device scale factor to be 1.f. This is different from real world, so the increment is expected.
I'm not sure if there is plan to change this. If there is a plan, I think someone from GPU team would be more appropriate than me.

[1] https://cs.chromium.org/chromium/src/cc/benchmarks/rasterize_and_record_benchmark_impl.cc?type=cs&q=RasterizeAndRecordBenchmarkImpl::RunOnLayer&g=0&l=199