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 18:20:14 -0700
Message-ID: <CANHK6RZPa+m+m_ykjYSSn7UfRQx2HCxFDBNyboi8bfAM824VnA@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Travis Leithead <travis.leithead@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Ted Mielczarek <ted@mielczarek.org>
On Thu, Jul 26, 2012 at 6:10 PM, Scott Graham <scottmg@chromium.org> wrote:

> On Thu, Jul 26, 2012 at 5:44 PM, Adam Barth <w3c@adambarth.com> wrote:
>
>> What triggers us to stop polling the gamepad?  When the object returned
>> by getGamepads() gets garbage collected?
>
>
> Currently, when the renderer goes away (or more specifically, when all
> renderers that are using the gamepad api go away).
>

Sorry, just realized I probably misinterpreted "us".

There's no particular indication at the spec level to indicate stopping the
gamepad polling, based on the assumption that it's an implementation
detail. Maybe there should be some way for content to hint that though?

I guess an implementation could timeout and shutdown background resources
if the content does not request data for some amount of time too.


>
>>
>> Adam
>>
>>
>> On Thu, Jul 26, 2012 at 4:32 PM, Scott Graham <scottmg@chromium.org>wrote:
>>
>>> 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 Friday, 27 July 2012 01:20:41 GMT

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