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

RE: [gamepad] Polling access point

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 26 Jul 2012 23:10:03 +0000
To: Scott Graham <scottmg@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
CC: Ted Mielczarek <ted@mielczarek.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38383E967C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
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


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?

Received on Thursday, 26 July 2012 23:10:38 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:44 UTC