[w3ctag/design-reviews] Gamepad API input events (#662)

Ya ya yawm TAG!

I'm requesting a TAG review of **Gamepad API input events.**

The [Gamepad API](https://www.w3.org/TR/gamepad/) requires applications to poll to detect new inputs. Many applications follow the spec's [recommendation](https://www.w3.org/TR/gamepad/#practice-timing) to coordinate polling with `requestAnimationFrame`. However, polling in this manner is likely to lose inputs since gamepads typically update more quickly than the animation frame rate. Polling will also increase average input latency by half the polling interval. This proposal addresses both the missed inputs and latency by adding input events that fire when the gamepad state has changed.

  - Explainer: [Gamepad API Button and Axis Events Explainer](https://docs.google.com/document/d/1At2ZsMOow4LmIhLs_LfnUV8J9glJS8qSyW-PqYtrQVA)
  - Specification URL: [Pull request](https://github.com/w3c/gamepad/pull/152) | [Preview](https://pr-preview.s3.amazonaws.com/w3c/gamepad/pull/152.html) | [Diff](https://pr-preview.s3.amazonaws.com/w3c/gamepad/152/bde81c8...bf1e7b2.html)
  - Tests: None yet, web platform tests will be added with the prototype implementation
  - Security and Privacy self-review: No security or privacy risks are expected since the events only expose data that is already available through the polling interface.
  - Primary contacts:
      - Matt Reynolds (@nondebug), Google, Spec editor, Implementer
      - James Hollyer (@jameshollyergoogle), Google, Spec editor, Implementer
  - Organization(s)/project(s) driving the specification: [Web Apps WG](https://www.w3.org/2019/webapps/)
  - Chrome Status: https://chromestatus.com/features/5989275208253440


Further details:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://w3ctag.github.io/design-principles/)
  - Relevant time constraints or deadlines: none
  - The group where the work on this specification is currently being done: Gamepad API is part of the [Web Apps WG](https://www.w3.org/2019/webapps/)
  - Major unresolved issues with or opposition to this specification: Event spamminess, see below
  - This work is being funded by: Google

You should also know that...

Gamepads can potentially produce a lot of input events and we are interested in feedback on how to mitigate the spamminess of these events. Consider a DualShock 4 that has two 2-axis thumbsticks and updates at 1000 Hz. When both thumbsticks are moving it will generate 4 axis change events per input frame, or 4000 events per second. If the application allows events to queue then it will be handling stale inputs, adding input latency.

This is mostly an issue for analog axis inputs but also affects pressure-sensitive buttons and analog triggers.

We have some ideas for mitigating this: 

* Combine all the button and axis changes that occur within an input frame into a single event so that at most one event is fired per input frame. This is analogous to how the [PointerEvents API](https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events) combines the X and Y axes of a pointing device into a single event object. The downside is that applications only interested in one type of input (for instance, button presses) will still be notified for every other input.
* Don't allow events to queue. Always deliver the most recent data, but provide a method for retrieving events that were not delivered. This is analogous to [getCoalescedEvents](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents) in the PointerEvents API.

See [here](https://docs.google.com/document/d/1rnQ1gU0iwPXbO7OvKS6KO9gyfpSdSQvKhK9_OkzUuKE) for more discussion on this proposal, the above mitigations, and comparison with the earlier Firefox implementation of these events.


We'd prefer the TAG provide feedback as:

  💬 leave review feedback as a **comment in this issue** and @-notify @nondebug and @jameshollyergoogle


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/662