W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [gamepad] Polling access point

From: Scott Graham <scottmg@chromium.org>
Date: Thu, 26 Jul 2012 16:32:17 -0700
Message-ID: <CANHK6RZudgNgUNo+iYq=z_mm7AjWP3m+S-+vc5mib3KX-AA6Sw@mail.gmail.com>
To: Travis Leithead <travis.leithead@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Ted Mielczarek <ted@mielczarek.org>
Thanks Travis, that seems like the "least surprising" solution.

I guess getGamepads() would be the preferred name by analog with
getUserMedia() then.

On Thu, Jul 26, 2012 at 4:10 PM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  Going to a function-based design is typically preferable (especially to
> making an attribute non-enumerable). This is the approach taken by
> getUserMedia.****
>
> ** **
>
> *From:* scottmg@google.com [mailto:scottmg@google.com] *On Behalf Of *Scott
> Graham
> *Sent:* Thursday, July 26, 2012 4:02 PM
> *To:* public-webapps@w3.org
> *Cc:* Ted Mielczarek
> *Subject:* [gamepad] Polling access point****
>
> ** **
>
> Hi,****
>
> ** **
>
> It looks like the access point for the polling part of the API
> (navigator.gamepads[]) is not a good idea.****
>
> ** **
>
> Based on a prototype implementation, pages seem to have a tendency to
> enumerate Navigator. When the .gamepads[] attribute is accessed, it causes
> possibly expensive background resources to be created to access hardware,
> even though the content is not really interested in reading data from the
> hardware.****
>
> ** **
>
> Possible solutions:****
>
> - change from navigator.gamepads[] to navigator.gamepads() (or
> navigator.getGamepads()) to be more explicit about when the API is actually
> being used****
>
> - require something to activate the API (meta tag, calling some sort of
> "start" function)****
>
> - require registering for at least one gamepad-related event before data
> is provided in gamepads[].****
>
> - make .gamepads[] non-enumerable****
>
> ** **
>
> Any thoughts or other suggestions?****
>
> ** **
>
> Thanks,****
>
> scott****
>
Received on Thursday, 26 July 2012 23:32:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT