Comment by sumtechguy

Comment by sumtechguy 3 days ago

4 replies

Also they probably ended up where they were because if I remember correctly windows will 'smash' mouse move events together for you in some cases. This will look like 'lost messages' (I recognized the peek loop as I have done that same thing once). This is is for two reasons one old not needed as much any more, and the one they found out the hard way. Memory as just scrubbing the mouse around would create a ton of memory objects that need to be pretty much cleaned up right away. The second is performance. As that is a ton of little messages that need to be picked up looked at and something done with. Which zorches your CPU.

The core of the issue is trying to wrap polling style of logic into an event based system (which windows is at its heart). There is no real pretty way to fix it.

leni536 3 days ago

I think it would be probably best to handle it like real time audio, 8kHz is not far off anyway. Just collect mouse sensor data at a fixed sampling rate into a ring buffer, and don't try to have a separate complex object for each sample.

maccard 3 days ago

> The core of the issue is trying to wrap polling style of logic into an event based system (which windows is at its heart).

Well said. The irony being that the event based system on windows is wrapping the polling of the USB device in the first place.

  • sumtechguy 2 days ago

    yeah. I would be the old win3.x/2.x code probably just hung out on the ps2/serial bus interrupt waiting for junk to show up. Then sending a messages along when it happened. That 'behavior' would have to stick around for MS to hit its backwards compatibility goals. Either sampling or event spamming with a debounce buffer.