On Sat, Feb 16, 2013 at 6:16 AM, Steve Fink <sf...@mozilla.com> wrote:
> 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. I think it is spec-compliant, actually, if we deliver the batched events as a series of individually dispatched mousemove DOM events. It might even be a reasonable solution. In bug 837985 it wouldn't be quite as good as coalescing --- we'd deliver multiple mouse-move events on each refresh driver tick, and all but the last one would do significant unnecessary work --- but it would stop the refresh driver from being starved so it would make that bug a lot better. The drawing application case would work perfectly. It could mess with the timing of sites that use Date.now() in a mousemove event handler to estimate mouse velocity. On the other hand that is already probably super-inaccurate over very short intervals. We could make event.timeStamp return the right thing anyway, if it's OK for DOM event dispatch order to not match the timeStamp order. I'm still not sure that this approach would be worth implementing. The extra precision for drawing applications doesn't seem like a big win given the mouse isn't a very good drawing tool anyway. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
