Re: [w3c/gamepad] Need to spec liveness of Gamepad objects (#8)

> That's not great, either store the JavaScript array object on the object and replace it when needed, or always create a new array based on the internal data

> `navigator.getGamepads()` has to return a new each time, because the return value is `sequence<T>`.

If Gamepad is a live object then the array returned by getGamepads() should only need to change when gamepads are added or removed from the list.

> Must, right? (Same for other shoulds.)

Yes, apologies, I'm new to spec language.

> This will have to be defined as updating internal state on the Gamepad objects at a specific point in time to avoid violating run-to-completion semantics. (You're saying as much at the end, but I hope the eventual definition of this will fall out of the processing model.)

> Regardless, last I knew the Firefox implementation actually implemented updates to `Gamepad` objects by doing the internal equivalent of queuing microtasks to update the state, so using some spec language like "Updates to Gamepad objects should be queued as microtasks in the current event loop" should both be sensible and not contradict the Firefox implementation.

> For when updates happen, I think there are three choices:

Let's go with "updates should be queued as microtasks in the current event loop" to match the Firefox implementation.

> Note that there have been requests to add support for the Gamepad API to Web Workers so ideally the spec text could be written to not make it more difficult to add that in the future.

@luser, can you elaborate on this? (Is there an issue with tying the update to microtasks or the event queue in a Web Worker?)

-- 
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/8#issuecomment-546090120