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

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


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

Android Nexus5 Perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1742b7a5640000

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

Comment and clean up code for marking layers to PushPropertiesTo. by danakj@chromium.org
https://chromium.googlesource.com/chromium/src/+/956d1c82d6e8263fecbd7d2240774a7363aea2c4
0.3888 → 0.4192 (+0.03035)

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

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

This is interesting, I think looking at the other metrics and traces the impl thread times have improved and FPS increased.  We're tickling what looks like an issue with how we limit PrepareTiles.

We're running slightly more PrepareTiles per-frame on average.  It's happening because the sample is still below 60Hz, and depending on how BeginFrames align, we sometimes get two PrepareTiles per Draw.


Sunny mentioned that moving the PrepareTiles throttling count to reset on Draw instead of on BeginFrame would remove the general issue.