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

Re: [Gamepad] Liveness of Gamepad objects

From: Ted Mielczarek <ted@mozilla.com>
Date: Tue, 29 Apr 2014 21:25:40 -0400
Message-ID: <53605114.7010403@mozilla.com>
To: Glenn Maynard <glenn@zewt.org>
CC: public-webapps <public-webapps@w3.org>
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
> 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.

This is a good point--if we have live objects then if we do implement
change events we'd need to store the state elsewhere. Firefox has
gamepadbutton{press,release} events and gamepadaxismove events[1][2]
(behind a pref), they actually do this already but it's not fantastic.

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

My original prototype provided the events mentioned above. The feedback
I received was overwhelmingly in favor of a polling API instead[3]. I
decided to go ahead with that (actually Scott beat me to the punch and
implemented that in Chrome first), figuring we could always spec events
in a future revision.

> I'd also be very surprised if I received a Gamepad object and its
> values were live--the interface looks like a snapshot.

The interface is...not incredibly consistent because I designed some of
it with the live object model in mind and Scott designed some of it with
the snapshot model in mind.

> On Tue, Apr 29, 2014 at 9:39 AM, Ted Mielczarek <ted@mozilla.com
> <mailto: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.
I meant mapping "navigator.getGamepads" to a poll of XInput and
returning the result for each gamepad there, not polling on each access
of .buttons/.axes.


3. https://bugzilla.mozilla.org/show_bug.cgi?id=604039
Received on Wednesday, 30 April 2014 01:26:09 UTC

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