Confirmed users
321
edits
JoystickAPI: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Created page with "{{bug|604039}} covers prototyping a way for web content to receive input from Joystick/gamepad controllers connected to a computer. = Initial Implementation = The patches curren...") |
No edit summary |
||
| Line 13: | Line 13: | ||
** unsigned long axis: axis number being moved | ** unsigned long axis: axis number being moved | ||
** float value: position of the axis in the range -1.0...1.0 | ** float value: position of the axis in the range -1.0...1.0 | ||
= Design considerations = | |||
* Should feel web-native. | |||
** DOM Events were chosen for the first prototype implementation because of the similarity to keyboard/mouse input. | |||
** Whatever API is chosen, it should use standard web idioms. | |||
* Should not expose the user to unnecessary fingerprinting. | |||
** Web pages should not be able to query for the number and type of attached devices without explicit user input. | |||
** Ideally we wouldn't have to use a permission infobar like with some other APIs, the user explicitly interacting with their device while viewing a webpage ought to be enough "permission" to send device data to that page. | |||
** The prototype implementation falls down a bit here, it sends events to all pages that ask for them, should really be just the foreground page. | |||
* Needs to be performant for web games that want to run at 60FPS | |||
** This will need experimentation and testing | |||
** There are assertions that DOM events won't scale to this level, it's possible that the API will need to be changed if that is true | |||
* To be useful, will need some way to map buttons/axes to meaningful values. | |||
** Even the same gamepad looks different on different OSes! | |||
** Across multiple devices this is insanity | |||
** Should try to expose enough info to let content handle this, Kevin Gadd has an "Input Device API" that is higher-level and might be a good fit here. | |||