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

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


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

chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-nvidia
chromium-rel-win7-x64-dual
chromium-rel-win8-dual

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14e8d0f4440000

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/14e8d0f4440000

Add device DMToken for affiliated user's policy requests. by poromov@chromium.org
https://chromium.googlesource.com/chromium/src/+/cbfc1f4ae00b331aad99f29148bc4bb40f5ff858

ScrollableArea rects need to be in coords of LocalRoot's Document. by wjmaclean@chromium.org
https://chromium.googlesource.com/chromium/src/+/5bed7ef3c3cfd01e4070792fdce590acbafab482

Revert "Supersize: Fix pak spurious deltas" by wnwen@chromium.org
https://chromium.googlesource.com/chromium/src/+/9b70a4435f46b08b4e5b19a0793a87a99f28045d

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

Seems unlikely to be "Add device DMToken..." since that's a Chrome OS feature and the bots complaining are windows. Seems likely to be wjmaclean's change?

Pak files change is only for the supersize tool.

bokan@ - could changing the coordinate computations really lead to this sort of perf regression? Not having the coords in the right space isn't really an option, so if it *is* this, then is there a more efficient way to do the computations?

The coordinate computations certainly wouldn't - but if we fixed touch rects that might alter which thread scrolls get sent to so it could have an effect in ways like that.

friendly ping from today's perf sheriff
any update, and action plan for this?

A friendly reminder for update.

CSM triage ping