I added tracing of the timestamps that go into this metric in https://chromium-review.googlesource.com/c/535658/. Tim we should get another trace with slippage and see what timestamps it's using on those frames that look like they're slipping.

Tim, just to confirm, did you mean to say Scheduling.Browser and not Scheduling.Renderer? The latter does seem to report about 21% of scrolls slipping on my Nexus 4.

My trace events show correct looking timestamps. When I observe long or slipping main frames in the trace the delta looks correct when it is activated. I suppose there may be a slight bias in that we only record this value when a new tree is used for the first time. This means that I think we can have several frames showing slippage (different scroll positions) drawn, but we'll just record one delta when the new tree is used.

D'oh - yeah, I think you're right that we were looking at the wrong metric.

WontFix.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5d42403d4924bdc879d4b278c56d31c7b4f3ee2d

commit 5d42403d4924bdc879d4b278c56d31c7b4f3ee2d
Author: Robert Flack <flackr@chromium.org>
Date: Fri Jun 23 16:43:46 2017

Record active tree main frame and impl frame times for delta metric.

To help debug the Scheduling.Browser.MainAndImplFrameTimeDelta2 metric, this
adds a trace of the times used to compute the impl and main frame delta. We
should be able to use this to identify which frames were identified as slipping
and when those times were recorded.

BUG= 719667 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I6ab1d6ca72f0c3ec186740d33014e8d39cfe8404
Reviewed-on: https://chromium-review.googlesource.com/535658
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Brian Anderson <brianderson@chromium.org>
Commit-Queue: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#481928}
[modify] https://crrev.com/5d42403d4924bdc879d4b278c56d31c7b4f3ee2d/cc/scheduler/compositor_timing_history.cc