Re: Running mousemove events from the refresh driver
On 02/14/2013 05:48 AM, Robert O'Callahan wrote: On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg benja...@smedbergs.uswrote: 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
Re: Running mousemove events from the refresh driver
On 02/14/2013 07:48 PM, Robert O'Callahan wrote: On Fri, Feb 15, 2013 at 4:44 PM, John Volikas fero...@gmail.com wrote: I tried the test on Nightly runnig Windows 7 64bit. I get up to 1000(!) mousemoves per second but I have a Logitech G400 gaming mouse that defaults to a 1000Hz polling rate without Logitech's software. I guess it depends on the peripheral and the OS. The lines are very smooth even with rapid mouse movements. [1] Selecting the checkbox to cap the rate and rapidly moving the mouse around results in a very ugly result though. [2] [1] http://ompldr.org/vaGd2bg/moverate.png [2] http://ompldr.org/vaGd2bw/moveratecapped.png Thanks. That is useful information. Unfortunately it doesn't help me figure out what to do :-). Rob It suggests a solution where a quick handler sees all mouse move events and batches them up, delivering the batches at a lower rate (60fps isn't completely unreasonable). Which is of course completely not spec-compliant. So as long as I'm ignoring the spec: have a quick handler that observes every move event. If nobody cares, drop them on the floor. If any standard handlers are defined, downsample them to 60fps and deliver one sampled move event per tick. If anybody registered for batched events, batch them up and deliver batches at 60fps. And/or if anybody registered for spline events, approximate them with a spline and deliver that at 60fps. (And set a max rate ceiling so you don't blow memory when some goofy test harness starts triggering mouse moves at 50MHz.) This completely and totally fails to solve the problem of regressing 1000Hz mice. Uh... reorder events? Send one mouse event per 60Hz tick, then deprioritize further events behind everything else, so that if the queue is empty then the remaining events are allowed through? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On 2/14/13 6:36 PM, Robert O'Callahan wrote: I created http://people.mozilla.com/~roc/mousemove-freq.html. We get up to 120-ish mousemoves per second on my machine in Firefox, and a bit more in IE9, but it caps out at 60fps in Chrome which suggests to me they're doing something like what I suggested already. Using my MacBook Pro's touchpad, Firefox maxes out at 60 fps, Chrome at 60 fps, and Safari at 120 fps. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
