The first bisect failed because "Bisect cannot identify a culprit: Bisect failed to reproduce the regression with enough confidence."

Started another bisect for https___mail.google.com_mail_ (which changed from 1.1ms to 4.1ms in the range): https://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6852.

Ah, for any page other than the specific partial invalidation page, I think the metric should be analogous to straight record_time. Checking:

https://chromeperf.appspot.com/report?sid=d0ebcf0314c34248d5d37281415620fbda893456d2578668eccee64a6760dd68

leads to  http://crbug.com/665331  which is closed as wontfix noting it looks like a window/viewport size change, and so a new baseline, and not a real regression?

The bisect job finished at: https://chromium.googlesource.com/chromium/src/+/5516863851ccc8158564461bb1c15af7f16436ac

With it we may invalidate bigger area than before on the scrolling contents layer. This might be the same as  bug 665331 .

Assigning to flackr to determine if we could fix this or just rebaseline the perf.