Re: [Gamepad] Liveness of Gamepad objects

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

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.

--Brandon

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

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