On 2/13/2013 10:48 PM, Robert O'Callahan wrote:
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg <benja...@smedbergs.us>wrote:
On what OSes? Windows by default coalesces mouse move events. They are
like WM_PAINT events in that they are only delivered when the event queue
is empty. See
http://blogs.msdn.com/b/oldnewthing/archive/2011/12/19/10249000.aspx
This should basically mean that we process mousemove events on windows up
to 100% CPU, but we should never be "flooded" by them. Although I do wonder
if WM_MOUSEMOVE has priority over WM_PAINT so that if the mouse is moving a
lot, that could affect the latency of WM_PAINT.
We are definitely getting flooded. Here's what I think is happening on the
page I'm looking at, it's pretty simple:
1) nsAppShell::ProcessNextNativeEvent checks for input events, finds a
WM_MOUSE_MOVE, and dispatches it, which takes a little while because this
page's mousemove handler modifies and flushes layout on every mouse move.
2) While that's happening, the mouse keeps moving.
3) After processing that WM_MOUSE_MOVE, ProcessNextNativeEvent calls
PeekMessage again and finds another WM_MOUSE_MOVE is ready. Go to step 1.
4) Meanwhile the refresh driver timer has fired and queued an event, but we
don't get around to running it until NATIVE_EVENT_STARVATION_LIMIT has
expired (one second).
I suppose we could try ignoring WM_MOUSE_MOVEs when there's a Gecko event
pending, but that sounds kinda scary. I think deferring DOM mousemove
events to the next refresh driver tick would be safer than that.
I think we should try to process mousemoves as quickly as we can: it's
important for certain kinds of drawing apps especially to have as much
mouse input as possible, and I doubt that only receiving mouse input at
60fps would be adequate in general. Can we build a very basic layer on
top of the OS mousemove events that coalesces them and dispatches them
as soon as there are no pending events (native or gecko)? This should
solve the problem of starving gecko events (especially refresh driver
events).
Other possible solutions are to special case refresh driver events in
the event loop and dispatch/coalesce them at specific times (ignoring
the native event starvation rules, for example), similar to what Windows
already does with WM_PAINT.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
