Extra SI_ZERO_EVENTs when slow processing SI_MOTION_EVENT

[harem]

If my application spends too much time (more than about 300 ms) handling a motion event, then it receives zero events in between motion events. I know it's not good to have such slow code in an event handler, but that's how it sometimes is. The zero events trigger more slow refreshes that compound the problem. Is there a way to distinguish these false zero events from real ones, stop them happening, or increase the timeout until they happen?

Here's an example of the sequence of events received without moving the controller to its zero position at any point, which you can see from the fairly similar position values in successive motion events:

SI_MOTION_EVENT Tx -22, Ty 0, Tz-206 Rx 336, Ry -5, Rz -43 Period 16
SI_ZERO_EVENT
SI_MOTION_EVENT Tx -28, Ty 0, Tz-208 Rx 340, Ry -4, Rz -41 Period 16
SI_ZERO_EVENT
SI_MOTION_EVENT Tx -27, Ty 0, Tz-212 Rx 338, Ry -3, Rz -37 Period 16
SI_ZERO_EVENT
SI_ZERO_EVENT
SI_MOTION_EVENT Tx -30, Ty 1, Tz-231 Rx 343, Ry -5, Rz -51 Period 16
SI_ZERO_EVENT
SI_MOTION_EVENT Tx -23, Ty 1, Tz-163 Rx 258, Ry -8, Rz -53 Period 16

[jwick]

More than likely what is happening is the driver is streaming events at the app at approximately 62Hz because you are pushing on the device. That application is ignoring them and the buffer is filling up. At that point, the driver doesn't want the application to just get the last motion event and never stop moving, so it sends a Zero event ("STOP MOVING").

We can increase wait times, all we want but apps will always get too slow for any wait time.

The best way to correct this is to put your 3D mouse event handling into a different thread. Then you are independent of whatever is causing the delay. Have that thread process the data and when it is convenient the drawing thread can ask this other thread for new device data.

You should put all your 3D mouse initialization, read, shutdown events into this new thread. It needs to have a window (for communication) but that window does not need to be displayed. It just has to be associated with your process so the driver can find it.

[harem]

Makes sense. Thanks.