1404519 - Consider coalescing mouse moves more aggressively when mouse button events are enqueued

Status: NEW

(Core :: DOM: Events, enhancement, P2)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Mouse button clicks and key events are more important to react to than mouse moves, typically. I've been doing some logging where I see us perform poorly because we're prioritizing all input events equally.

One example:
- mouse-button message arrives at 0ms
- at 419ms we finish processing the event we were working on when it arrived
- at 419.9ms we process a mouse move event and coalesce it
- at 420ms we do a vsync where we run a mouse move event handler
- at 425ms, after the vsync finishes, we process another mouse move event and coalesce it
- at 425.9ms we do another vsync, but we don't do any work because of this branch:
http://searchfox.org/mozilla-central/rev/20e41d4a61a8f5e34c9cf357304b78b3e9bced8a/layout/base/nsRefreshDriver.cpp#1826
- then we process a ton of random events. I think we don't process more input events because of this test:
http://searchfox.org/mozilla-central/rev/f2b181af9497af258d96213f2f0cfccc08740a86/xpcom/threads/PrioritizedEventQueue.cpp#159
- finally at 434ms we process the mouse button event

Ideally, at the 419.9ms mark, we would have coalesced all the mouse moves we've received before the mouse button event, dispatched that event, and then immediately dispatched the mouse button event.

Comment 1

[Ming-Chou Shih [:stone]]

Could we check whether the input events in the queue can be coalesced and process them (in thread level) when there are no higher priority events? We won't really dispatch them to content but coalesce them in TabChild. Then we can process the pending input events which cannot be coalesced before vsync.