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

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


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

Android Nexus5 Perf
Android Nexus5X WebView Perf
Android Nexus6 WebView Perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/110e2172e40000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/110e2172e40000

Noisy graphs for this benchmark, triggering alerts and failed bisects. Assigning to owner to fix.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15688b2ee40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/121e348ee40000

I think the alert point wasn't accurate enough to generate a good range for pinpoint.  There seem to be two regressions, before and after the range that got bisected in #3.

Graphs: https://chromeperf.appspot.com/report?sid=a272b731ecf48253fcb596409a221128905fd0b293bfa9fa11fcb33bf244a12f

#5 triggers a bisect on 'thread_browser_cpu_time_per_frame' in range 597107-597166.

#6 triggers a bisect on 'thread_other_cpu_time_per_frame' in range 597366 - 597393.

The first one is likely crrev.com/597137, which is expected to increase cpu-usage a bit since we are dispatching more events, and thus doing more work, per frame.

The second is likely crrev.com/597373.

> The second is likely crrev.com/597373.

Hmm, we need to revert DSF enablement on Android too then.

#11: A proper fix for the solid color quads regression is almost ready (issue 879379), so I don't think we need to revert the dsf change. 

M71 is branching tomorrow.  We need to adhere to principles of revert first, fix later.

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

Revert "solid color quads workaround for use-zoom-for-dsf" by eirage@chromium.org
https://chromium.googlesource.com/chromium/src/+/d7d5990bc6b25d7b7ce711b035147030e778879a
thread_other_cpu_time_per_frame: 7.646 → 8.207 (+0.5608)

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

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

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

Reland "synthetic gesture: Allow high-frequency dispatch." by sadrul@chromium.org
https://chromium.googlesource.com/chromium/src/+/a66784e0fd71f686f1d7152902137619608c6c80
thread_browser_cpu_time_per_frame: 2.224 → 2.411 (+0.1868)

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

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

 Issue 893862  has been merged into this issue.

 Issue 893596  has been merged into this issue.

The regression caused by reverting the workaround should be fixed by https://chromium.googlesource.com/chromium/src/+/159ad145dd83238fb3d27e709205f9a5cec84be3

I see a dip in https://chromeperf.appspot.com/group_report?bug_id=893860 for thread_total_all_cpu_time_per_frame. It'd be interesting to see if it persists.

Yeah, CPU times are back down.  Other examples: https://chromeperf.appspot.com/report?sid=49819f8b6a1b198cc20a09360e425f1fb5c447f5c28fdbb52b91c3264ffa95fa

I'm a bit concerned that we may have regressed GPU power especially on CrOS, because now we are not creating smaller quads that can be culled.

Related benchmark drop back after Yi's change. (some of them are even better than before :D)
Thanks Yi!

Issue 893178 has been merged into this issue.

 Issue 871347  has been merged into this issue.