Re: [w3c/gamepad] Make gamepads accessible by web worker (#37)

Exposing the Gamepad API to workers is a basic requirement for most modern games.

The main thread is often too busy to respond to user input immediately, causing a noticeable delay. Games that require accurate input (rhythm games, fighting games etc) and games that already struggle with input latencies (anything with online multiplayer) cannot possibly tolerate the input latencies that are inevitable on the main thread.

The WebMIDI API is being updated to support MIDI in workers and audio worklets, specifically because realtime audio is not feasible with main thread latencies.

The only reason keyboard and pointer events are tied to the main thread is because they're part of the DOM API.

There is a proposal to expose keyboard and pointer events in workers. It hasn't made much progress, but threaded keyboard and pointer APIs will eventually happen, as many applications require them.

In any case, taking gamepad input, which is intrinsically global (unrelated to the DOM) and marrying it to the DOM's event system is a terrible idea, if that's what you're proposing to do. We already have a bunch of Web APIs that handle user input (WebUSB, WebMIDI, WebBlueTooth and WebSerial), which all have events, but none are tied to the DOM, and they're all available in workers (or will be eventually).

Conflating gamepad events with DOM events is a categorical error.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/37#issuecomment-1345720567
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/37/1345720567@github.com>