How about this idea: after processing a WM_MOUSEMOVE event, go into an "anti-flood" state where WM_MOUSEMOVE is ignored. After we service the Gecko event queue, exit the anti-flood state.
This is very simple and I think it would work well for all cases. When DOM mousemove handlers are cheap and there isn't much else going on, we'll be able to fire mousemove at very high rates. But when mousemove handlers are expensive (bug 837985) we'd never delay processing the Gecko event queue (and running the refresh driver) by more than the duration of one mousemove handler. 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
