Here's a trace on my Nexus 6p: https://drive.google.com/open?id=0B9JF7Oi4NUhPX1R3NGtfUnEtOWc.  First half is scrolling the top controls, second half is just scrolling the page (all in one gesture).  The problem is obvious from the input latency graph (attached).  I don't see anything obvious in the trace consuming extra work though, and if anything the total CPU usage is higher when scrolling than when hiding/showing the top controls.  A scheduler bug perhaps?

Deleted: Screenshot from 2016-11-24 09:58:19.png 22.1 KB

	Screenshot from 2016-11-24 09:58:19.png 22.1 KB View Download

Looks like this is fixed in the latest Canary so the regression was fixed somewhere between 56.0.2919.3 - 57.0.2931.0. I'm bisecting to find the cause.

This was caused by

commit 4ba3a0e9d06bf66b3d900fec44bcf8ee4a2964a2
Author: samans <samans@chromium.org>
Date: Sat Oct 29 02:27:45 2016
Getting rid of DelegatedFrameData

And fixed by the revert in 

commit eb9ecefc55d1e3cf8498d0865568097fb9bbf285
Author: aelias <aelias@chromium.org>
Date: Wed Nov 16 06:27:00 2016
Revert "Getting rid of DelegatedFrameData"

Android Dev channel hasn't picked up the revert yet but everything should be ok on the 56 branch and on ToT now.

BTW, in case you don't know, Clank also has a script to exact bisect without local compile nowadays.
 https://docs.google.com/document/d/1gm32bNauYaSL-0Yq-O5plJI73SnjWWpUSEMb5_350TE/edit#heading=h.5osh8abtl9u

Usually the command will look like: python clank/tools/bisect-archived-builds.py -a arm --apk chromium -u -o -g 428590 -b 428592

Yep, that's what I used. Super helpful :)