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

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


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

Android Nexus6 WebView Perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15aae407a40000

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

Enable use-zoom-for-dsf on Android on M70 by eirage@chromium.org
https://chromium.googlesource.com/chromium/src/+/d0b8bbd2dbf9c06dcbbd01a4b1285cf7a1bc2ba0
15.71 → 27.45 (+11.74)

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

I think this is expected, since the test iterating the area with a fixed size. Before the flag enable, the pixel is in dip, but it's physical pixel after. so the rasterize took more iterations, result in the rasterize_time increase significantly.

Thanks for investigating this.

+benchmark owners, FYI

Reopen because the size is actually causing problem and not only the test.

Confirmed with vmpstr@ that the regression is due to the test doesn't apply dsf, which is different from real world. So this regression is expected and would not cause real harm.