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 17:34:21 +0000
Message-ID: <CAEGwwi3fisu7CRK_Y4gZgtM_1SwC9qUCF=4LyS_bwEbnSquCuQ@mail.gmail.com>
To: Brendan Eich <brendan@secure.meer.net>, Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org, "Mark S. Miller" <erights@google.com>
I don't think that API design should be driven by implementation details,
but it may be useful to provide some background on Chrome's Gamepad
implementation here:

The current polling-only API Chrome uses is largely due to practicality
with the multiprocess architecture. The gamepad data is acquired in the
central browser process, placed in shared memory, and then polled by the
tab processes when getGamepads() is called. This cuts down on a lot of IPC
overhead that would otherwise result from constant "Hey, Gamepad N
changed!" messages broadcast to all tabs.

Given that, if we decide that the gamepad objects should be live and not
snapshots I think that Chrome will probably put a system in place where the
first access of a gamepad object property does a behind-the-scenes poll and
then does not poll again until control has been given back to the browser.
(Which is probably not an issue since many games will be processing input
in a rAF loop.) I can't think of any scenario where a forced policy of "one
update per frame" would be detrimental, but I'm open to feedback on the

If it were my call I'd vote for gamepad objects being snapshots simply
because it will add some additional overhead to make them live and it avoid
concerns about observing GC, but I don't really object to either design.


On Tue Apr 29 2014 at 10:18:24 AM, Brendan Eich <brendan@secure.meer.net>

> Boris Zbarsky wrote:
> > For what it's worth, the way Gecko implements this is by setting up
> > that lifetime guarantee only when an expando is added to the object
> > (or some other things, like use as a WeakMap key, happen).  Until then
> > we allow it to be GCed.
> What do other engines do in general? Unobservable GC is a requirement,
> if you ask me and Mark Miller.
> /be
Received on Tuesday, 29 April 2014 17:34:49 UTC

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