Issue metadata
Sign in to add a comment
|
Better understand EventHandler::HandleMouseMove latency
Reported by
jer...@duckware.com,
Aug 20 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36 Steps to reproduce the problem: 1. Enable "D3D v-sync" in chrome://flags 2. visit vsynctester.com in Windows 3. notice how the blue line is very flat 4. move the mouse and notice over 1ms delay in calling rAF (jump in blue line). What is the expected behavior? The mouse handler on the web page was changed to return immediately (do nothing) and that changed nothing. There was still a 1ms delay. That is large compared to the entire frame of just 16.6ms. So the 1ms delay is internal to Chrome some how? What went wrong? rAF aligned input should not add this much delay to the rAF callback. Did this work before? Yes before rAF aligned input was turned on Chrome version: 60.0.3112.101 Channel: stable OS Version: 6.3 (Windows 8.1) Flash Version: tested on a Dell Inspiron 15-3543 notebook (Intel i5-5200U 2.20Ghz with 2 cores (4 threads), Intel HD Graphics 5500, 4GB, Windows 8.1).
,
Aug 20 2017
Another (smaller) test case: http://www.duckware.com/test/chrome/rafaligned.html
,
Aug 20 2017
,
Aug 21 2017
Please include a trace for performance bugs: See https://www.chromium.org/developers/how-tos/submitting-a-performance-bug
,
Aug 21 2017
See attached. Trace of http://www.vsynctester.com/index.html?noevents. Graph shows when mouse was moved. Web page has no mouse event listeners.
,
Aug 21 2017
Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 22 2017
Also, issue only appears with mouse rAF aligned input. On the same computer, touch rAF aligned input does not appear to have an issue delaying rAF. What is going on with mouse internal processing to cause this?
,
Aug 22 2017
Thanks for the trace.
So the difference between touch and mouse is that mouse is hit test on every event whereas touch is captured implicitly to the event that had the touch start.
So in a gaming app for example you'd likely use pointer lock which doesn't pay the penalty of hit testing.
Looking at the CPU time of a single mouse move:
RWHI Handle Input Event: 0.910ms
- WebView Handle Input Event: 0.800ms
- Event Handler Handle: 0.747ms
- Update Style/Layout 0.073ms
- Update Layer 0.092ms
- Hit Test: 0.198ms
There seems luck a good portion of time (0.384ms) in EventHandler that is unaccounted for; adding tracing might help us better understand that portion.
,
Sep 4 2017
The NextAction date has arrived: 2017-09-04
,
Aug 22
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 23
nzolghadr@: You've been looking at mouse latency issues, do you think we still need some additional tracing here? |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by jer...@duckware.com
, Aug 20 2017