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

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


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

mac-10_12_laptop_low_end-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1297ce16640000

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/1297ce16640000

Move TimeClamper to core/timing by dgozman@chromium.org
https://chromium.googlesource.com/chromium/src/+/2c38ce9585da7b0d07aff3b03faf8085548f1c6e
54.05 → 52.24 (-1.817)

blink/canvas: Ensure constant PaintImage::ContentId for canvas snapshots. by khushalsagar@chromium.org
https://chromium.googlesource.com/chromium/src/+/f93f8b7c3d3080586deba2a1a7f6b47bcfc4e340
52.56 → 60.32 (+7.754)

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

-dgozman@, Its definitely my change.

I'm super confused with how this change increased the number of tasks. Its curious that there is a decline in the number of tasks on the same benchmark from https://chromium.googlesource.com/chromium/src/+/79531c77e491dc9536c985d6c4f5dcd8c6bb48b8, which also regressed the behaviour that the patch above fixes.

fserb@, does anything in the traces jump out to you, that would explain why the initial change reduced the number of tasks and this change would increase them back?

Faster rendering can lead to more tasks per unit time. pdr and vmpstr
investigated a similar "regression" recently.

Thanks Chris, that is probably the case here as well. The change above is an overall improvement in smoothness and frame_times (https://chromeperf.appspot.com/group_report?rev=584588) and the tasks_per_frame_total_all regression for this config is minor in comparison to the improvements everywhere else. I think the change is working as intended.

 Issue 876844  has been merged into this issue.