Re: [Gamepad] Liveness of Gamepad objects

On 4/29/2014 1:34 PM, Brandon Jones wrote:
> 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.
I think what I'll wind up writing in the spec will describe the liveness
in terms of tasks[1], which is how web specs talk about the event loop
nowadays. Something like "changes in the state of the gamepad should
queue a task in the task queue to update the state of the Gamepad
object". So your proposed implementation would match that exactly, which
is nice. This is what we're already doing in Firefox, either by virtue
of simply handling input on the main thread, or posting events from a
background thread that's handling input.

Performance-wise, I think this will wind up being functionally
equivalent to your existing implementation anyway--assuming that content
is polling navigator.getGamepads() in a rAF loop, you're going to be
delivering one state update per frame anyway.

>
> 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.
>
Anne mentioned the observable GC concern, he said the spec should state
that the lifetime of Gamepad objects is tied to the lifetime of the
global, which isn't too terrible. (There aren't going to be a ton of
them in play anyway.)

I agree that having to make an architectural change like this sucks, I
wish I had spec'ed it better from the beginning. I certainly don't want
to enforce the Firefox implementation as correct just because it's mine,
that's why I started this discussion.

-Ted

1.
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task

Received on Tuesday, 29 April 2014 18:45:35 UTC