On 02/14/2013 05:48 AM, 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.
Hmm, why do we call PeekMessage at that point and not go to gecko event loop.
IIRC we still have the problem at least on OSX that we check native events too
often.
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.
Rob
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
