Re: [w3c/gamepad] Should fire events instead of using passive model (#4)

When thinking about what sort of event api would be useful, I think it is helpful to divide the use cases into categories based on how they expect input.

**Reactive**: input is a cue for something to start happening. Examples: video player, slideshow viewer

In this category we mostly get web apps that want to be able to interact or navigate occasionally with a gamepad. These apps want events because the current api forces them to poll continuously even though they rarely process input.

For the majority of cases, reactive apps only want to know about:
1. Button fully pressed
2. Button no longer fully pressed
3. Axis reaches +1.0 or -1.0
4. Axis no longer at +1.0 or -1.0

Tracking slight changes in joystick inputs does not make sense in events, because it produces many more events than a reactive app can reasonably respond to. An additional catch-all event GamepadChanged could be used if necessary but it might need both rate limiting and noise tolerance to be useful.


**Animated**: input is processed continuously and at regular intervals. Examples: games, simulations

An event driven api could help these types of applications catch missed button presses and improve timing, but the reality is that events are a poor fit for these types of apps. @pyalot pointed this problem out earlier.

> Note that using events exclusively without control over the event loop has severe data handling drawbacks.

These classes of applications aren't idle, and therefore don't need an event to fire to wake them up. The need to listen for and store events to be used for the next game/simulation loop is a nuisance.

What these apps ideally want is a way to get all available information about the gamepad between the current game/simulation loop and the previous one. Specifically that means providing a function that can retrieve for snapshots of gamepad state or gamepad state changes over a specified time interval.

An example api change that can accomplish this is to add an optional parameter of type DOMHighResTimeStamp on getGamepads, which will cause each gamepad to instead be returned as a sequence of all gamepad states after the provided time instead of a single gamepad.

Providing all gamepad state updates has important benefits:
1. Timing accuracy no longer limited by polling rate, and by extension, frame rate.
2. Inputs will not be missed or have inaccurate timing if the browser freezes briefly.
3. Can consistently determine the order and combinations buttons are pressed in.

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