Things you should know about Windows Input, but would rather not
Modern PC games are running into surprising problems with input handling on Windows, especially when high‑polling‑rate mice flood legacy message queues and hurt performance or break basic window interactions. Developers debate how to balance low‑latency, consistent input (often via raw input or newer APIs like GameInput) against compatibility needs such as window movement, overlays, IMEs, and controller quirks, with some suggesting workarounds like borderless fullscreen modes or even offloading input to separate processes. The thread also contrasts Windows with macOS, Linux, and Wayland, highlighting that every platform has its own fragile edge cases around keyboards, mice, and game controllers.
Overall reaction to the article
- Several commenters appreciate the explicit invitation for experts to critique the solution, seeing it as very “hacker spirit” and akin to using public writeups to attract better ideas.
- Many confirm that Windows input is indeed a mess of legacy and modern APIs with surprising edge cases.
Raw input, NOLEGACY, and message queues
- Commenters reiterate that once NOLEGACY is enabled, you can’t switch back to legacy messages at runtime; RIDEV_REMOVE kills all input.
- Some propose synthesizing legacy messages yourself, but others note Windows tracks “real” vs synthetic events, which can break default handling and embedded components (e.g., WebView2).
- There’s debate on how to structure message loops: some argue you should drain the entire queue and ignore unwanted messages in the handler, rather than selectively peeking.
Fullscreen vs borderless and input lag
- Experiences differ: some find AAA titles only stable in true fullscreen; others say “borderless windowed” usually gives the best tradeoff of performance and Alt‑Tab behavior.
- Newer flip-model presentation (DXGI / DX12-era) is mentioned as the key to low-latency borderless modes; support only became practical once older OS/DX versions could be dropped.
High-polling mice and performance
- 8 kHz mice can flood queues and hurt performance; some have had to lower polling rates to avoid stutter.
- Others downplay the problem, arguing that processing thousands of events per second shouldn’t be expensive, but game developers counter that real games do regress.
- There’s debate over whether dropping events is acceptable; some note HID already reports deltas, so not every event must be processed for accurate motion.
Keyboard layouts, WASD, and input expectations
- Many complain games inconsistently treat WASD as characters vs scancodes, breaking non‑US layouts and layout switching.
- Multiple commenters insist games should:
- Use scancodes for bindings (positional behavior).
- Use OS APIs to map those to display labels.
- Raw vs accelerated mouse input is debated: competitive players favor raw input; others argue defaulting to OS behavior is better for casuals.
Controllers, APIs, and alternatives
- Old joysticks/wheels often need calibration; newer engines and APIs sometimes ignore system-level calibration, breaking older hardware.
- GameInput is suggested as a unified API but is criticized for missing legacy devices (e.g., Xbox 360 pads) and not solving the message-flood issue.
- Some suggest offloading raw input to a separate process or ring-buffer style handling, arguing multi-process designs are underused.
Other platform quirks
- Wayland compositors can drop clients when event buffers overflow.
- IME behavior (especially Japanese) and Shift timing for capitals are cited as broader, long-standing UX issues across platforms.
- Rust game-dev tooling (e.g., winit) still struggles with repeat keys and timing, especially on X11.