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 <scot...@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.leith...@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:* scot...@google.com [mailto:scot...@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**** >> > >