Putting this as P2 cause I think this would have impact on the results of experiments. Feel free to change the priority.

Sahel, is this something you can take a look into?

This metric only measures the latency for the first GSU event (generated from the first wheel tick) of every scroll sequence. It used to record one sample per wheel tick since when wheel scroll latching is disabled every wheel tick has its own scroll sequence and they were all first events in their own scroll sequence. Now that wheel scroll latching is enabled the metric records only latency for GSUs generated from the first tick only.

https://chromium-review.googlesource.com/c/chromium/src/+/699210 cl adds Event.Latency.ScrollUpdate.Wheel.TimeToScrollUpdateSwapBegin2 metric to measure latencies for the GSU events generated from the non-first wheel events of scroll sequences. This change makes the two metrics similar to equivalent metrics for touch scrolling.

We were seeing fewer than 1 sample per series of scrolls, so I think there is something broken here.

Yes, xidachen@ showed me the case that we scroll and no sample gets recorded, seems like wheel scrolling on main thread doesn't record samples properly.
Trying with wheel_scroll_latching and async_wheel_events disabled didn't change anything, I will investigate more.

I cannot reproduce the problem on 64.0.3269.0:
With wheel scroll latching enabled I see exactly one sample for Event.Latency.ScrollBegin.Wheel.TimeToScrollUpdateSwapBegin2 per scroll sequence and when the flag is disabled I see multiple samples recorded for a scroll.
xidachen@ could you please take look to see if the problem is still reproducible or not?

sahel@: as we discussed offline, I can still repro this on linux desktop, using gmail.

cc'ing Chris as he was seeing the same issue.