Wheel events can pile up on mac (not coalescing across flings) |
||
Issue descriptionVersion: 51.0.2702.2 OS: Only checked Mac for now What steps will reproduce the problem? 1. http://rbyers.github.io/scroll-latency.html 2. Set handler jank to, say, 500ms 3. do a bunch of short flings up and down What is the expected output? I _think_ we'd want the wheel events to get coalesced together (as they do on ChromeOS) What do you see instead? The wheel events pile up and can keep going for quite a long time after the input stops (in this pathological example). dtapuska@ pointed out that this is probably because the wheel events on Mac contain phase information that prevents coalescing. Perhaps our coalescing should be more aggressive? The implications of changing this aren't immediately obvious to me (how is the phase information used?). This is probably long-standing so not urgent (maybe WontFix). I was just surprised to see the behavior when testing passive event listeners (generally mousemove,touchmove or wheel queuing up indefinitely almost always feels wrong).
,
Apr 11 2016
Eventually we may want to expose phase information to developers, so this is potentially developer facing. Phase information is currently used for things like the overscroll effect. I think this is equivalent to touchstart events not coalescing across flings. I suppose we could coalesce touchstart events across flings in some cases, but it feels pretty scary. I'd be inclined to WontFix, but keep it in mind. This should be no worse than touch.
,
Apr 11 2016
That's a good point that a wheel sequence can be thought of like a touch sequence. If we allow a series of swipes to pile up, why not a series of wheel gestures? A site would have to be pretty pathologically bad for the user to notice. I.e. coalescing should be used for animation-like events since a 60hz responsive main thread is not easy to achieve or common, but "response" events are at most running at 7hz (150ms each) and really it's always a bug if the page isn't processing events that quickly. We could consider a mitigation in extreme cases (eg. dropping input that's more than a second or two out-of-date), but I haven't seen evidence that users would benefit from this in practice. So the only remaining issue I have here then is the difference in behavior between platforms. To what extent will the work on wheel gestures get us similar behavior on Aura? If there's a bug we can point to that, when addressed, will make Aura and Mac behave similarly here then I'm OK calling this WontFix.
,
Apr 11 2016
Issue 526463 will require adding phase information (sometime generated via timer) across all platforms. |
||
►
Sign in to add a comment |
||
Comment 1 by rbyers@chromium.org
, Apr 8 2016