Regression on ScrollBegin.Wheel related to vsync align input |
|||||
Issue descriptionIt seems that vsync align input caused some unexpected regression for wheel scrolling: https://uma.googleplex.com/p/chrome/timeline_v2?sid=faaa0a0533051dad4884bdb36adcbd36 which can be verified from the Finch trials as well. https://uma.googleplex.com/p/chrome/variations/?sid=80c83c1062c3ecf911a4f7c3872bf218 It seems that part of the code will be going away completely after latching and latching will almost recover that regression. https://uma.googleplex.com/p/chrome/variations/?sid=13522c988ce51ce41bc69b3772e7be59 Sahel, you are more familiar with that part of the code. Do you have any idea how vsync aligned input could have caused that regression on Mac? We couldn't come up with any scenario related to this. Note that the same graph got improved on Windows and almost no change on Linux. https://uma.googleplex.com/p/chrome/timeline_v2?sid=a6edb3d40f6a6c8df51a85aee887645c
,
Jan 16 2018
With RAF aligned input on the main thread side and Vsync aligned scroll handling on the compositor, two frames can pass between creation of a wheel event and handling of its corresponding GSU. https://chromium-review.googlesource.com/c/chromium/src/+/849313/2/ui/events/blink/input_handler_proxy.cc changes the code to flush the Vsync queue when the wheel source of a GSU is handled blocking. An alternative solution might be for blocking Wheel/Touch events not to wait for the RAF signal, and then no need to flush Vsync queue, Dave knows more about this and why we might need it.
,
Jan 16 2018
Assigning Navid as we need a clear owner for P1 issues.
,
Jan 22 2018
,
Jan 22 2018
> flush the Vsync queue when the wheel source of a GSU is handled blocking. Would that help in practice or would it just improve the metric? Isn't the point of vsync aligned scrolling that the output of the scroll won't be noticed by the user until vsync anyway?
,
Jan 22 2018
The problem with having both RAF aligned input handling for wheel events and Vsync aligned scroll handling is that in some cases there might be two frame delays between creation of a wheel event and handling its corresponding GSU. This delay is also visible in real cases not just the performance metrics.
,
Jan 22 2018
Yeah, I just mean would flushing the vsync queue when you get the GSU actually help in that case since the updated position won't make its way to the screen until the swap anyway...
,
Jan 22 2018
I think the regression is visible in Event.Latency.Scroll*.Wheel.TimeToScrollUpdateSwapBegin2 as well, nzolghadr@ might know more.
,
Jan 25 2018
A few things to add. Here is the latest updated version of the Finch charts: https://uma.googleplex.com/p/chrome/variations/?sid=6c79654c82f3ba1d7aad387c80788d90 As you can see clearly Event.Latency.ScrollBegin.Wheel.HandledToRendererSwap2_Main was the metric that regressed. I created a page to force chrome to scroll on main and scrolled on my mac but I couldn't get any of that metric recorded. Here is the page: https://output.jsbin.com/lucine Anyone has any suggestion?
,
Jan 29 2018
Anyone any idea how to proceed?
,
Jun 7 2018
As latching change the code path quite a bit and improved the metric and almost recovered the regression in 65 https://uma.googleplex.com/p/chrome/timeline_v2?sid=b51c64ce15411e3603fe92165d684c88 I will close this issue. However, I'll add the wheel scrolling metrics to the Chirp alert pool as well so that we get notified if anything happens. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tdres...@chromium.org
, Jan 16 2018