- From: Matt Reynolds <notifications@github.com>
- Date: Wed, 25 Aug 2021 16:16:33 -0700
- To: w3c/gamepad <gamepad@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/gamepad/pull/152/c905938268@github.com>
@jakearchibald > Event coalescing can be used to get more detailed axis changes, but even then I wouldn't expect multiple events with the same type and timestamp. Actually, this would be very common. Gamepads are usually implemented using the HID protocol or something similar where all button and axis values are delivered in a single packet. If you're moving a joystick then it's likely you'll see updated X and Y axis values in the same packet, which would result in two axischange events with the same timestamp (but different axis indices). > Having an equivalent of pointerrawupdate also seems ok. Perhaps there should be a gamepadchange event that fires at some reasonable time synchronized to rAF and provides coalesced events, and a rawgamepadchange event that fires for every change and doesn't coalesce? I'm looking at the [pointermove](https://www.w3.org/TR/pointerevents3/#the-pointermove-event) spec and it looks there's no guidance on when the event should be fired if it's delayed. For gamepadchange I think it would be good to explicitly specify that if there's a pending gamepadchange event then it must be fired before rAF. That lets applications synchronize on rAF if they need to consume some inputs through getGamepads() polling and some through events. -- 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/pull/152#issuecomment-905938268
Received on Wednesday, 25 August 2021 23:16:46 UTC