Fixing high polling rate mice on Windows in Godot
Godot 4.7.2 ships with a Windows-specific fix for high polling rate mice, removing a nasty performance cliff that could appear as soon as mouse updates climbed past roughly 1–2 kHz on typical modern CPUs. In bad cases, moving the mouse with an 8 kHz device could collapse framerate into the single digits or even below 1 FPS in captured mouse mode.
The root problem is Windows’ input path: requesting raw input still delivers legacy mouse messages too, and at very high polling rates that can overwhelm the engine’s event handling. Godot now buffers raw reads in DisplayServerWindows::process_raw_input(), delays WM_INPUT dispatch in process_events(), and limits legacy mouse motion to once per frame. Other inputs such as keys, buttons, wheel, and gamepads keep their existing paths.
The payoff is substantial. On a 480 Hz test setup, 8 kHz mouse movement went from under 1 FPS in Godot 4.7.1 to about 477 FPS in 4.8.dev3, with 1% lows improving by 45.8x in one benchmark. The fix is already in 4.7.2.stable, and it matters most for Windows projects that use captured or visible mouse input at high refresh rates, or that need to behave well on slower CPUs and laptops.
“With great polling rate comes great responsibility.”
- what
- Godot 4.7.2 includes a Windows fix for high polling rate mice, preventing severe framerate drops from mouse input flooding.
- who
- The fix is in Godot Engine, with implementation inspired by PH3’s prior work on the same Windows input problem.
- when
- The fix landed in Godot 4.7.2.stable; 4.8.dev3 was the first development snapshot to include it.
- impact
- Windows games and tools built in Godot should avoid catastrophic stalls when players use 2 kHz, 4 kHz, or 8 kHz mice.
Major Windows input perf bug is fixed in a stable release.
Discussion