#662: Gamepad API input events
Discussions
2021-08-23
Ken: this makes sense. They're not going to remove polling so you can still poll if you want. Getting events seems reasobable. One issue - button down or up - people are moving to a world where it depends how much the button is down, adaptive triggers - depends on how much or force feedback. Should some thought be given on how to support this as well?
Dan: kind of out of scope for this propoosal...
Ken: some considerations... a whole new API - or a buttonPressed event, buttonReleased event?
Yves: wouldn't it be better ... poll at regular intervals?
Ken: that's what they have today - it means if you're not good at polling enough then you lose event data.
Yves: if it's an analog value every small change in the pressure will release lots of different events. How do you filter? what is the granularity?
Dan: coalescing strategy for event mitigation
Ken: get coalesced events that returns the events combined
Yves: as multiple events?
Ken: you get one event that is the coalesced event, but you can get the original events
Yves: you can imagine you want the median value of ten different events that happen roughly at the same time?
Ken: that's what they give you by default. Some kind of medium.. join the events somehow. But then you can get the original events by calling getCoalescedEvents
Dan: the proposal is by google people. Scant information on additional support for this (e.g. in the ChromeStatus)
Yves: do they have specific events for accelerometers?
Ken: I don't know.. pretty sure they did something for VR
Yves: pretty sure accelerometers should be read every time because you want to know exactly what's going on
Ken: you don't want to coalesce accelerometers... draft doesn't seem to have anything on accelerometers
Dan: writes comment
Ken: does the event have a timestamp? In the gamepad interface.. why does that have a timestamp? Not part of the... [leaves comments]
2021-09-27
Dan: long comment back from requester
Ken: [reads] .. they're asking [something].. I'm going to ask dominic. Feedback seems positive.
Dan: there's a PR.. happening in webapps but the explainer is still in a google doc, I'll ask them to bring the explainer over.
Ken: will add Anne
Dan: if we get feedback by tomorrow we could close at plenary. Other reason to keep it open?
Ken: wait and see. Want to see if Anne and Dominic think their comments.. maybe easy to close, let's wait.
2021-09-Gethen
Dan: Taking at look at the response to our last comment. Looks good to me.
Rossen: they are coalescing everything by design in a single packet...
2021-12-Madripoor
Dan: Can we close this off?
Ken: My concern is .. it's unclear .. two different events but can't use both at the same time... Two modes of getting the events... coelesced and non-coalesced. Grey area... Should there be a start function like we have with generic sensors?
Ken: writes comment regarding side effects...
2022-02-28
Dan: The issue that Ken raised has not been.. not clear whether it should be a blocker. I think this sounds fine.
Sangwhan: some flaws in original gamepad API - they're aware of this - this is trying to fix some of them... 2ndary interface.
Sangwhan: ... I think this is fine.
Dan: Ken is comparing it to generic sensor API?
Sangwhan: Ken's idea would make things complex - for each event listener you would have differnt ways of handling things -- complicate implementation. I can understand both sides of the argument...
Dan: if it adds complexity.. The user need is articulated well. People want to play games.
Sangwhan: writing games with current web tech is not good, you have to implement a poll inside RAF. This fixes some of that because it lets you develop games in a way that web apps are supposed to be made, so the api is less horrible. I feel like this is good.
Dan: agree
Sangwhan: I'll say if it's a tradeoff with complexity it's okay for now, might want to revisit in the future
2022-02-28
Rossen: Close?
Dan: pending external feedback. Need to be happy with response. Need Sangwhan's input.
OpenedAug 4, 2021
Ya ya yawm TAG!
I'm requesting a TAG review of Gamepad API input events.
The Gamepad API requires applications to poll to detect new inputs. Many applications follow the spec's recommendation 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.Further details:
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:
See here 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