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
