Re: [gamepad] Polling access point

What triggers us to stop polling the gamepad?  When the object returned
by getGamepads() gets garbage collected?

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