- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 29 Apr 2014 18:28:31 -0500
- To: Florian Bösch <pyalot@gmail.com>
- Cc: "Mark S. Miller" <erights@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, Brandon Jones <bajones@google.com>, Brendan Eich <brendan@secure.meer.net>, public-webapps <public-webapps@w3.org>
- Message-ID: <CABirCh-cNmDioNVU+EvY4QSUUr+U_h8VVZWMXwrdfcSpF_YnWg@mail.gmail.com>
Gamepad objects should definitely be a snapshot. Otherwise, change events could only expose the most recent state of the gamepad. For example, if the user presses a button and then releases it very quickly (before the down press gets handled by script), and you fire two change events, the script would never see the buttons as pressed. (That said, I'm confused--where's the event to tell the user that the gamepad has changed? Surely this API doesn't require the developer to poll, which would lose inputs at the slightest GC skip and could never give high resolution timing.) I'd also be very surprised if I received a Gamepad object and its values were live--the interface looks like a snapshot. On Tue, Apr 29, 2014 at 9:39 AM, Ted Mielczarek <ted@mozilla.com> wrote: > snapshots and see what's changed. (Additionally as an implementation > detail this maps very well to the Windows XInput API, which is a > polling-based API.) > You can't just map a "gamepad.xButton" property to "NativeInputAPI.getCurrentXButton()", because you need to guarantee that if you read the property twice in a row without returning to the event loop the result is always the same, even if the button state changes while the script is executing. You could prevent this by caching the result and clearing the cache when scripts aren't running, of course. On Tue, Apr 29, 2014 at 2:27 PM, Florian Bösch <pyalot@gmail.com> wrote: > I think both semantics are workable. I'd likely prefer the gamepad state > to be immutable from JS, because assigning state there is smelly. I'd also > prefer the option that incurs less GC overhead if possible. Beyond that, I > just think the implementations should be semantically and symbolically > identical. > No, the object should be mutable, since most web API objects have mutable properties. If I want to do things like gamepadState = getGamepads()[0] // Run the input logic, but pretend the A button isn't pressed: gamepadState.aButton = false; checkInput(gamepadState); then I should be allowed to. There's nothing strange about this in a JS API. -- Glenn Maynard
Received on Tuesday, 29 April 2014 23:28:58 UTC