Gamepad Event-Driven Input API

concepts

1. Latency Comparator

   Two readouts of the same gamepad: one polled in requestAnimationFrame, one driven by rawgamepadinputchange. The numbers in each panel are the time between input events — lower is better.

2. Button timeline

   Every gamepadbuttondown, gamepadbuttonup and gamepadaxismove drops a mark on a 5-second rolling timeline. Sub-frame events show up as separate ticks — something a 60Hz rAF poll could never capture.

3. Button Visualizer

   Live map of every button and axis on your connected gamepad. Each button box highlights on press and shows the raw pressure value; axis tracks move in real time — all driven by rawgamepadinputchange events with a polling fallback for other browsers.

4. Game Input Recorder

   Records a sequence of gamepad inputs as a timestamped macro, then replays it. Uses the event-driven API to capture inputs at the device's native rate — including sub-frame events — and displays a comparison of event-driven vs rAF-polled recordings to show the fidelity difference.

5. Compatibility Lab

   Detects rawgamepadinputchange, gamepadbuttondown/up, and gamepadaxismove event support. Shows live gamepad connection status, logs events from a connected controller, and falls back to requestAnimationFrame polling automatically. Provides the universal input-handler pattern with both paths.

why it exists

Today the Gamepad API only exposes state via navigator.getGamepads(), which sites poll every frame. That gives you input quantised to your render cadence — typically 16ms granularity at 60Hz, and worse if the main thread stalls. High-frequency gamepads (240Hz+) feed input far faster than that. rawgamepadinputchange fires on every input change at the device's true rate, so games can read state with sub-frame fidelity and react to button presses that happened mid-frame.

references

• ChromeStatus entry
• Gamepad spec