On Fri, Feb 15, 2013 at 10:14 AM, Benjamin Smedberg <benja...@smedbergs.us>wrote:
> 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). > That could starve mousemove events, though. 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. In that testcase you can artificially limit mousemove frequency to 60 per second. It doesn't make much difference to my drawing, athough I'm poorly coordinately. But wouldn't it make sense for a drawing app to intelligently interpolate between mousemove points anyway, using splines or something? I sort of doubt the difference between 60 points per second and 120 points per second is critical. And I *really* doubt we should design for that constraint. 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
