Its sort of doing that. Right now, if the event is fired and
followed by another event within .05 of a second, the initial event
is ignored. Any mouse event that last .05 seconds without another
mouse event being fired is sent to the server. You'd think this
would cause lag, but the removal of all the unnecessary messages, and
the lag they caused, actually makes the interface more responsive.
There is a second condition in which the event can be fired. If you
are only making moves within a 10 pixel range, it will periodically
send the message anyway (about twice a second with the current, very
The parameters could be tied to a GUI slider eventually, though my
experience with modifying the timeout value is that it might as well
be hard coded.
Finally, right now, if the mouse button is down, it continues to
follow the previous rules. The more I think about it, I don't see
any difference between a drag and a non-drag. If you are moving the
mouse quickly, you probably don't care that the server knows where it
was, because you are already ahead of the server. And if you are
moving slowly, you still only need to send a couple messages a
second, because network lag dictates that most of those extra
messages don't mean anything anyway (except for the server to wait
forever to process things you did in the past). The key is to make
sure that before mouse sensitive events (mouse up, down, etc) you
make sure that the last unfired mouse move is sent out first no
matter whether under other circumstances you would ignore the event.
>Jared, I haven't had a chance to play around with it yet (maybe Sunday
>before I get the time), but I want to put my vote in for a tunable
>pref *exposed in the UI*. I say this as a System Administrator of 20
>years who ran into mouse-tracking issues with some applications, and
>the ability to modulate the rate of queue empty or transmittal is, in
>my opinion, vital. "mouse performance" could be the slider name.
>With "better performance" == 'longer queue'. ;-)
>As for the algorithm, what I would like to see (but think it would be
>very complicated) is something that takes into consideration the
>distance between the mouse location at "this" event from the "last"
>event, and if it's far, then assume the mouse is moving quickly, and
>flush the queue later. If it's close, then assume it's small
>movement, and flush more often. If it's within a couple of pixels,
>and short durations, then assume it's jitter and punt.
>I see an axis, of sorts:
>| A B
>| C D
>A = slow mouse tranmissions
>B = fast mouse transmissions
>C = really slow mouse transmissions
>D = fast mouse transmissions
>As a network weinie, I don't want to see more than a pair of packets
>per second for "most" mouse movements. At idle, I'd want none, of
>course, and during mouse-down movement, I want them all, and damn the
>Just my $0.02 worth. :-)