Gamepad Event-Driven Input API

at a glance

why it exists

The existing Gamepad API requires polling: you call navigator.getGamepads() inside a requestAnimationFrame loop, which runs at most at the display refresh rate (typically 60 Hz). A gamepad can report input at 1000 Hz or higher. The gap means input events can be 1–16 ms stale before the application sees them — unacceptable in competitive games or precision controllers. An event-driven model fires immediately when the hardware reports new data, independently of the frame rate, enabling applications to respond at the device's native rate.

shape of the API

One new event on window that fires for every hardware input report:

rawgamepadinputchange event

example

Event-driven input loop (replaces polling)

// Previously: polling inside rAF
function pollLoop() {
  const gamepads = navigator.getGamepads();
  if (gamepads[0]) {
    handleInput(gamepads[0]);
  }
  requestAnimationFrame(pollLoop);
}

// With rawgamepadinputchange: fires at device rate, not frame rate
window.addEventListener('rawgamepadinputchange', (event) => {
  handleInput(event.gamepad);
});

Low-latency button handler

window.addEventListener('rawgamepadinputchange', (event) => {
  const { gamepad } = event;

  // A button (index 0) — fire at native device rate
  if (gamepad.buttons[0].pressed) {
    triggerAction(gamepad.index, 'A', gamepad.timestamp);
  }

  // Left stick X axis
  const leftX = gamepad.axes[0];
  if (Math.abs(leftX) > 0.1) {
    moveCharacter(leftX);
  }
});

relation to the existing Gamepad API

browser support

see also

• chromestatus — Gamepad Event-Driven Input API (5989275208253440)
• W3C Gamepad spec (working draft)
• Chromium bug — crbug.com/40582297
• Live demo: gamepad raw input events
• w3c/gamepad issue #4 — long-running request for gamepad events
• chrome-platform-showcase: Gamepad Event-Driven Input API demos (when built)