Godot 4.7.2 fixes severe performance drops from high polling rate mice on Windows

Godot 4.7.2 has resolved a performance issue that plagued Windows users with high polling rate mice. The problem manifested as severe framerate drops, sometimes falling into single digits, when using mice configured to poll at 2 kHz or higher.

High polling rate mice have become increasingly common since the early 2020s as manufacturers pushed beyond the traditional 1 kHz standard to 2 kHz, 4 kHz, and even 8 kHz. These higher polling rates reduce input latency and provide more consistent mouse updates, which matters particularly on high refresh rate monitors that can exceed 144 Hz. However, Windows was not designed to handle thousands of mouse updates per second, creating a mismatch between modern hardware and the operating system's input architecture.

The issue occurs because Windows sends both legacy input events (WM_MOUSEMOVE) and raw input events (WM_INPUT) simultaneously when applications request raw input for games. Raw input was introduced in Windows XP to allow games to bypass OS processing like mouse acceleration. However, when raw input is requested, legacy input continues to arrive, and this dual stream of events at high polling rates overwhelms the input queue, causing frame rate to collapse.

The performance threshold where this becomes problematic varies depending on mouse movement speed and CPU single-core performance, but on most modern CPUs running recent Windows 11 versions, it typically occurs somewhere between 1 kHz and 2 kHz. Mice with higher polling rates push past this limit quickly during normal gameplay.

Godot's fix treats mouse motion inputs separately from other input types to prevent input system congestion. The solution performs buffered reads in the DisplayServerWindows::process_raw_input() function and uses the Windows API PeekMessageW() function to prevent raw input from being dispatched immediately. Instead, raw input remains queued for the next buffered read. Legacy inputs are dispatched only once per frame at most during non-captured mouse modes, avoiding performance issues while maintaining compatibility with window dragging and other expected behaviors.

Other input types, including keyboard and mouse buttons, are handled using the previous approach since they do not arrive frequently enough to cause congestion. Gamepad input remains on a separate system and is unaffected by this fix.

This issue was not unique to Godot. Thousands of games across Windows have suffered from high polling rate mouse problems since the early days of Windows gaming, with non-captured mouse modes being particularly prone to performance loss. Linux users running either Wayland or X11 were generally not affected by this issue regardless of their game engine or mouse configuration.

Developers using Godot should still optimize their _input() and _unhandled_input() functions, particularly code paths called for InputEventMouseMotion events. With input accumulation enabled by default, these methods may be called multiple times per rendered frame during fast mouse movements, such as 480 times per second on a 480 Hz monitor with V-Sync enabled.