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

[Gamepad] Liveness of Gamepad objects

From: Ted Mielczarek <ted@mozilla.com>
Date: Tue, 29 Apr 2014 10:39:36 -0400
Message-ID: <535FB9A8.7080203@mozilla.com>
To: WebApps WG <public-webapps@w3.org>
The only major issue that needs to be fixed in the Gamepad API spec
currently is the liveness of Gamepad objects[1].

Currently this is implemented differently in Firefox and Chrome--Firefox
uses "live" Gamepad objects, in that you can take the .gamepad property
from a GamepadEvent or a Gamepad from navigator.getGamepads(), assign it
to a variable, and check its state on every pass through the event loop
to get the latest values of .buttons[]/.axes[]. Chrome uses "snapshot"
Gamepad objects, so the Gamepad you get from navigator.getGamepads() is
static, and you have to call getGamepads() on every pass through the
event loop to get the latest state of the controller.

I obviously have a bias towards what I've already implemented, but I can
see the appeal of both approaches. With the "live" approach you can take
a Gamepad object and assign it as a property of another object and use
it that way, like "player.input = gamepad", which makes it easy to
manage Gamepad input as part of other code. With the "snapshot" approach
you can easily save an old snapshot so that you can compare two
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.)

Does anyone have any feedback on which of these seems more natural? Is
there any precedent in the web platform to prefer one approach over the


1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434
Received on Tuesday, 29 April 2014 14:40:05 UTC

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