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

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


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

android-nexus5
android-nexus5X
android-nexus6
android-nexus7v2

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/129b403d840000

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

Use LocalFrames in ScrollingCoordinator compositing update. by wjmaclean@chromium.org
https://chromium.googlesource.com/chromium/src/+/0e7b308819ce2a660b1b86393f5fa56ff817c369

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

So far as I know, --site-per-process isn't turned on for these bots on Android, so the only effect here *should* be the different method for computing the same rects. If it's leading to different values than we had before, causing events to be handled on a different thread, that would be worrying, though it's presumably possible.

bokan@ - is there any chance the new computations don't work the same on Android?

There shouldn't be any coordinate differences for Android - more likely is that its broken on all platforms but Android is the only one running high-DPI so it's the only platform that composites the scrollers.