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

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


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

android-nexus5X
android-nexus7v2
chromium-rel-mac11-pro

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16a75290840000

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

cc: Avoid main thread latency recovery during loading.
By khushalsagar@chromium.org · Tue Jan 09 19:25:03 2018
chromium @ 2f9cdf26e68f1fc58a978216b0e4d97eb660a2d3

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12e79764840000

I've started another bisect since the bug seems quite unrelated to the change in #3.

+tdresser, But investigating this, I'm looking at the latency info for the first scroll update event and I see the most increase in the time between Display::DrawAndSwap until when InputLatency::GestureScrollUpdate ends. This is the time we're waiting for a swap ack from the GPU right?

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/148996d8840000

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

Make front buffer manipulation NOTREACHED
By backer@chromium.org · Tue Jan 09 20:50:39 2018
chromium @ 4d9fb08430a1f94e315dd0ab79c42ae3f998ba99

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

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

cc: Avoid main thread latency recovery during loading.
By khushalsagar@chromium.org · Tue Jan 09 19:25:03 2018
chromium @ 2f9cdf26e68f1fc58a978216b0e4d97eb660a2d3

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

I moved the thread times regression from the bisect in #8 to  issue 804696 . The smoothness regression came back to the main thread latency change.

Oops, +tdresser for realz.

I'm not exactly sure what I'm supposed to look for here. I see 2 traces for Latency::ScrollUpdate. The one in renderer is way lower (18 ms to 11 ms) and the one in the browser increased (2.5 to 4.8) And the most increase seems to be between the Display swap and when the trace ends, which I'm assuming is swap ack. I'm also a bit confused with how this change could have had any impact. It just makes sure we don't skip the second main frame during loading, and it doesn't look it had any impact there. We were never skipping that frame anyway. Tim, any ideas?

Re #6, yeah, that should be time spent waiting for the swap ack.

We shouldn't be showing LatencyInfo slices for the renderer. Navid, any idea what's going on?

I'd say the next step is to request full traces, with all disabled by default categories. Could "not skipping the second main frame" result in us doing more rendering work? That might not explain this example fully, but I can see how doing a bit of extra rendering early in page load could block the handling of the first scroll update event.

Hmmm, let me get more tracing with cc to see what's going on. The part that confuses me is that we were not skipping the main frame prior to the change anyway, so its likely something else.

Looks like the metric is back close to the pre-regression value (~3ms). I don't think there is anything worth investigating here. There was a scheduler change that triggered this and minor fluctuations are expected.