On Jul 18, 2005, at 4:00 PM, Jared McIntyre wrote:

Except that the OS is doing that based on the responsiveness of a local computer(and I don't think it is even doing that, in most OSes it is straight forwarding the hardware interrupts as it gets them which is why the number of mouse messages you get a second depends on the type of mouse you are using).  74 mouse move messages a second is insane when you add network lag (even local network). 

74 is most definitely insane. :)

But I haven't seen this.  What I've seen is that the only messages Chicken receives are necessary ones, it doesn't seem to receive anything extraneous.  Are you by any chance using a non-standard mouse driver, like SideTrack or something that might have been included with a 3rd party mouse?

I could definitely be wrong on this - I've never really paid attention to it, I'm just going on my (possibly flawed) recollection.

Each mouse message is waiting to be sent (for .05 seconds), or to be replaced by the next message (which will also wait).  If a message is sent to the server, that mouse message that is waiting is sent immediately.  The code to do this isn't particularly nice since it is proof-of-concept code, but it seems to work.

That sounds solid.  

If you'd like, by the way, I have a little Event Mangler app I used to do the development of the EventFilter class.  It basically feeds events from a view through the filter to a dummy RFBController.  Might be useful for testing.  Let me know if you'd like the code.  

I was thinking that it would be profile based, since you may want to do this differently on a per computer basis.  I see there being two preferences.  The first is how many mouse move messages do you want to allow a second.  I think this should be 1-4.  If people want an "all" then that could be added, but I personally don't think it is necessary (or good).  The other is how far a pixel move needs to be for it to be looked as a potential forced mouse move.  I don't know how to explain this in a user preference, but effectively, if it is zero pixels, the mouse moves won't be sent until the mouse stops, and if it is infinite, it will always send 1-4 messages per second depending on the previous setting.  Anything in between will allow really fast movements to be completely ignored (unless we have to send it per the discussion earlier) since you probably don't care about them, but fine movements will be paid attention to.  Right now I have it set at 10 pixels.  I think that even that is a bit too wide for my tastes.

I'm all for dead-simple, non-geeky UIs.  So, my preference is that if we find that this is a useful and non-destructive modification, it's on-by-default, no preference exposed to the user.  If it's useful but possibly problematic (like my graphics package scenario), it's something dead simple like a "Coalesce mouse movement" checkbox in the connection profile.  

Number of mouse movements sent per second is geeky - the non-technical user has no clue if they want 7 or 5 or none or infinite.  :)