I think we can tweak the current logic a bit to coalesce events even more. Patch coming.
Or there are various options here. aEvent.mTimeStamp < mLastWheelProcessedTimeFromParent could become something like aEvent.mTimeStamp < mLastWheelProcessedTimeFromParent + TimeDuration::FromMilliseconds(250.0); Or just always coalesce when the next message is wheel, and use time comparison only when peeking some more messages.
Or another approach is to coalesce more on pages which use lots of time in wheel listeners. That sounds better. We already do that by having mLastWheelProcessedTimeFromParent, but we could punish such pages even more.
Created attachment 8866737 [details] [diff] [review] wheel_coalesce_more.diff I filed this bug after profiling Google Spreadsheet scrolling on the Quantum Flow reference hw. https://treeherder.mozilla.org/#/jobs?repo=try&revision=97caf8e72e488326b9ff86d73fc95a43e41f8f9e The approach shouldn't be too aggressive, since we after all try to coalesce only if there are some wheel events in the IPC channel. Relying on the processing duration should make this scale better in different kinds of setups: on slower machines this lets us coalesce more.
There's also the "compress" option in IPDL. We seem to use it for RealMouseMoveEvent but I don't see it being used for wheel stuff.
(In reply to Andrew McCreight [:mccr8] from comment #4) > There's also the "compress" option in IPDL. We seem to use it for > RealMouseMoveEvent but I don't see it being used for wheel stuff. That's because we want to accumulate the delta values of the coalesced wheel event and compensate them to the event we dispatched.
Comment on attachment 8866737 [details] [diff] [review] wheel_coalesce_more.diff LGTM, thanks.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1944785ec625 Coalesce wheel events more aggressively, r=stone