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

> A common failure mode of this kind of thing is when you have say an X and Y axis and you're plotting say a position on screen from them. So the X axis event arrives first, you draw a line there, then the Y axis event arrives, and you draw a line there. Now you've got a staircase instead of a continous line.

This problem is easily avoidable if you can get multiple events at once. In your example you get an X axis but have no way of checking if the Y axis event has already fired and is waiting to be processed.
 
- If you implement an event that provides an array of changes, you always see the events together.
- If you implement an event that provides only a timestamp of when changes occured and allow getGamepads to request states over a time range, you will see both axis changes within the states.
- As long as the api provides a mechanism to deal with this problem, it may be okay to leave in some events that suffer from this issue if it makes the implementation of gamepad support easier for simple use cases.

> Although getting the whole state (as is presently the case) avoids that kind of issue

Take the simple case that a controller has a directional pad, and you want to perform different actions for up, diagonal (up + left) , and right. When polling the complete state, just left or just right can (and frequently will) show up in a poll before both show up together unless the are pressed together at exactly the same time. You can't avoid doing the left or right action before diagonal unless you buffer inputs for some arbitrary interval before performing the left or right actions. There are a lot of similar issues like this that need to be tackled by the application and are unlikely to be solved directly by the api.

> there is also sometimes a case to be made for having the ability to collect the events for axes and then aggregate them yourself (for instance instead of just using the last known, you can do a weighted average). For very twitchy games, this can provide players with a more satisfactory response.

I am very much in favor of games aggregating events or state provided from the API, and believe this is the ideal way to handle input. The question is how to collect the aggregated events.

**1. Poll Spamming** (the current way)
Call getGamepads on a timer with a short interval and collect the gamepad states.

- It already works and is a simple and understandable solution.
- There is no way to know what polling rate the hardware is using or sync to it, so we are frequently undersampling (increased latency, missed inputs) or oversampling (wasted timer calls).
- If the main javascript context stalls for any reason inputs are missed and timing loses accuracy.
- The polling loop is constantly active even if the controller is idle.

note: Timing is much worse than accessing hardware directly in Chrome due to a counter being provided instead of timestamps and internally buffering with a long polling interval. (In my test case 125hz hardware is polled and buffered at 60hz)

**2. Event Listeners** (same as mouse and keyboard)
Api would provide events to subscribe to that fire for every possible state change on connected gamepads. The application subscribes to all event types with functions that collect the events.

- Fits in better with existing input handling of mouse and keyboard events.
- When the controller is idle, no events need to be handled.
- High update rate hardware can result in quite a lot of event handling spam.
- No missed inputs or inaccurate timing.

**3. Query State/Events** (my suggested method)
Have the browser internally poll or accept input from all active controllers with as much accuracy as possible and buffer this information over a short period. Expose an API that takes a time range and returns an collection of states or events from gamepads over that time range.

- No input events or timers in javascript. (better efficiency?)
- No missed inputs or inaccurate timing.

A minimal API to satisfy all possible use cases: 
- Add one event for when any gamepads have change state after a specified time. 
- Add an optional start time range to getGamepads so it can return multiple states.

-- 
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-248420592