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

Thanks for the comments, @kenchris

> Are there strong cases to be able to configure how events are being dispatched? If not, please just choose one.

There's a strong case to dispatch input events immediately to support streaming game clients. For cloud gaming, inputs need to be uploaded with minimal latency. The `rawgamepadchange` event is intended to satisfy that use case and any other case where low latency is needed. Currently, the only "good" way to do this is to poll `getGamepads()` as quickly as possible, which still adds a small amount of latency. Events tied to the animation frame loop aren't useful for this use case because they add latency, on average half the interval between animation frames which will always be worse than rapid polling.

The case for having a coalesced `gamepadchange` event is that there can potentially be a huge number of `rawgamepadchange` events. The input rate is determined by the gamepad hardware, not the user agent. If script can't keep up with the events then they'll queue and add latency. By flushing all events any time one event is fired, script is always processing fresh input data but still has access to all the historical input data since the last event. Synchronizing on the animation frame callback is convenient because that's where most applications currently process gamepad inputs.

> If you really need it, then couldn't this be configured with a method instead, with a sane default.

I think configuring the dispatch behavior with a method on the Gamepad object could work. Probably `gamepadchange`'s coalescing behavior should be default so the user agent can control the event rate if needed. Changing from a coalescing mode to a non-coalescing mode should flush pending events to ensure no inputs are lost.

Is there any precedent for configuring the event dispatch behavior after an event listener is registered?

> Also, events cannot have side-effects so you would have to have the implementation be prepared to dispatch both events at all times. Listeners to one event type cannot change how events are being dispatched internally.

I may have worded this confusingly, I want to specify the same behavior as in Pointer Events where "The user agent MUST fire a pointer event named [pointermove](https://www.w3.org/TR/pointerevents3/#the-pointermove-event) when a pointer changes button state." The intent is to flush the `gamepadchange` queue whenever a button's `pressed` attribute changes regardless of whether any event listeners are registered.

> If you have oninputchange, I don't think we should add onbuttondown and onbuttonup - It is better to teach developers to actually just use the other event. I don't think onbutton* adds any convenience - but they might add confusion

I agree, if the `gamepadchange` overhead is tolerable then `buttondown` and `buttonup` don't add much. I think it's reasonable to drop them.

> Adaptive triggers is more than just controlling haptic feedback such as vibration. It is also about having non-binary values for buttons. Like a machine gun (in a game) might start shooting faster and faster the longer down you press the button.

I may have misunderstood your original suggestion. Non-binary button values have always been supported by Gamepad API and in this proposal we'd fire a change event whenever a trigger value changes. I've only heard the term "adaptive triggers" used in the context of DualSense's adjustable tension.

I think you're suggesting `buttondown` and `buttonup` could be generalized in a way that better supports non-binary buttons. Instead of firing a single `buttondown` when the trigger value crosses the button press threshold, we would fire multiple `buttonpress` events as the value increases.

If we're dropping `buttondown` and `buttonup` then this is moot.

-- 
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#issuecomment-921385045