Re: [gamepad] Polling access point
On Thu, Jul 26, 2012 at 9:20 PM, Scott Graham scot...@chromium.org wrote: 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. I was thinking that this isn't much different than the use case in the geolocation API spec[1]. Perusing that spec shows that it has watchPosition / clearWatch APIs for explicitly registering/unregistering for location updates. I don't know if I particularly want to add an API like that, but conceptually we might want something like that. In my current implementation in Firefox, the background polling is triggered by the page adding event listeners for one of the DOM events. I don't recall offhand if unregistering for the events stops the polling, or if it takes having the document unloaded. -Ted 1. http://www.w3.org/TR/geolocation-API/
RE: [gamepad] Polling access point
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
Re: [gamepad] Polling access point
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
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 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
Re: [gamepad] Polling access point
On Thu, Jul 26, 2012 at 5:44 PM, Adam Barth w...@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). Adam On Thu, Jul 26, 2012 at 4:32 PM, Scott Graham scot...@chromium.orgwrote: 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
Re: [gamepad] Polling access point
On Thu, Jul 26, 2012 at 6:10 PM, Scott Graham scot...@chromium.org wrote: On Thu, Jul 26, 2012 at 5:44 PM, Adam Barth w...@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 scot...@chromium.orgwrote: 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
