The logs indicates I would get a steady stream of delta's as expected(maybe a dozen a second), then BOOM, I'd get a few thousand in a very short period. When my engine applied the 1000 delta's it would move right to the boundary. When I considered the problem. I could not work out a good way to see if an update was at normal speed or was a spam update. So... I needed a new system. Hence this post. My current interim solution is to just set the internal mouse to the system mouse position whenever the WM_MOUSEMOVE comes in. The spam burst seem to not affect framerate so I can ignore it for now.

You should'nt handle every cursor move event by any further logic than simple remembering of it.

You should set your own explicit delta depending on your program frequency, and peek for computing newest explicit delta the time you decide to observe the explicit difference.

This is done that at every MOUSEMOVE message you simply save the difference by pushing it to some array (most of the time you want to algebraicaly add them), and then you are able to find out new most current explicit delta the moment you observe this MOUSEMOVE deltas-pumped array.

Some gamer mouses fires incredible amounts of MOUSEMOVE events, 1000 a second at least, when you disable certain mouse behaviors in windows for example.

It is totaly standard, it gives high input resolution to the gamer, but your program must handle properly this intense information.

If you will handle every event by some advanced definitive logic influencing your program, you will experience event-dummy artifacts. This applies even for keys.