W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [Gamepad] Liveness of Gamepad objects

From: Brandon Jones <bajones@google.com>
Date: Tue, 29 Apr 2014 23:42:14 +0000
Message-ID: <CAEGwwi2naXE6Y1P1akJSHcOzOfQOrNQT3-gE+VVWZipUsRcfMA@mail.gmail.com>
To: glenn@zewt.org, pyalot@gmail.com
Cc: erights@google.com, bzbarsky@mit.edu, brendan@secure.meer.net, public-webapps@w3.org
On Tue Apr 29 2014 at 4:28:31 PM, Glenn Maynard <glenn@zewt.org> wrote:

> (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.)
>

This is slightly off topic, but worth addressing. The spec does not, in
fact, have any change notifications. Firefox has some experimental ones you
can enable but they're not official. This does indeed provide an
opportunity for input loss, but I'm not aware of anyone who's actually
found it to be a problem. (Given the sparse number of apps using the API,
though, that doesn't say much.)

This is good feedback, though. It may be that snapshot + change events is
the most effective way to go?


> 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.
>

No complaints here. A good use-case for mutable properties may be a JS
script that intercepts gamepad snapshots and re-maps them in-place to a
standard mapping if the browser has not already done so.
Received on Tuesday, 29 April 2014 23:42:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC