Throttle WM_MOUSEMOVE messages to avoid being overwhelmed by them with high-frequency mice

[filipppavlov]

When the client processes Windows messages it tries to process all of them until the message queue is empty.
When the player is using high-frequency polling mouse, it is possible that new mouse move message will be generated while the client processes the previous mouse move message, and this can happen repeatedly. As a result, the framerate in the client noticeably drops when a player is moving the mouse.

Normally, Windows will coallesce mouse move messages, so that there are no subsequent WM_MOUSEMOVE messages in the queue. The slowdown issue only appears when the client removes the mouse move message, and processes it, and in the meantime the new one arrives.

This change is a safest workaround for the situation I found. If the client has just processed a mouse move message, and there are no other messages in the queue aside from a new mouse move message, stop event processing for the frame. The leftover mouse move message will be processed on the next frame.

This way the client still processes any other messages that come in during the previous frame or generated while processing other messages in this iteration, only postponing the last mouse move message.

[ccptoebeans]

I may be missunderstanding the processing of windows events here, but messages are being removed by PeekMessageW being called with PM_REMOVE here. If we simply stop processing mouse events, is this not a memory leak?

[filipppavlov]

No. The message will stay in the queue until we get to process it on the next frame.