Re: [gamepad] Add an event-based input mechanism
On 10/13/2014 3:03 AM, Chad Austin wrote:
Just as I mentioned in my previous email to this list, I recently was
asked to review the Gamepad API draft specification. My background is
games though I've done some scientific computing with alternate input
devices too.
http://chadaustin.me/2014/10/the-gamepad-api/
I'd like to make a second proposed change to the gamepad API, an
event-based mechanism for receiving button and axis changes.
The full rationale is explained in the linked article, but the summary is:
1) an event-based API entirely avoids the issue of missed button presses
2) event-based APIs don't require non-animating web pages to use
requestAnimationFrame just to poll gamepad state
3) an event-based API could (and should!) give access to
high-precision event timing information for use in gesture recognition
and scientific computing
4) event-based APIs can reduce processing latency when a button
changes state rapidly in low-frame-rate situations
Thanks for the feedback! I think we've been fairly starved for useful
feedback from people with real-world experience. My first implementation
of the Gamepad API in Firefox was solely event-based. The code is still
present in Firefox (it turns out to be useful in testing, if nothing
else), you can enable it by flipping the
dom.gamepad.non_standard_events.enabled pref in about:config. It
generates gamepadbutton{down,up}[1] events and gamepadaxismove[2] events.
I encountered a lot of pushback after making my initial implementation
public indicating that developers wanted a polling-style API, and then
Scott proposed and implemented navigator.getGamepads(), and then I
didn't have the mental stamina to try to figure out the right way to do
events. On the plus side, I think adding events on top of the existing
spec would be fairly straightforward and wouldn't break anything. On the
minus side, someone still needs to figure out what they should look
like. :) Obviously the set of events that Firefox implements is not
great. The gamepadbutton{down,up} events are probably close to what we
want, but gamepadaxismove is terrible.
Right now the #1 priority is getting the existing Gamepad API specified
in an interoperable way, given that we have three
pretty-well-interoperable implementations. I've found it hard to find
the time to finish that spec work up, but I plan to make time in the
near future. Once we can get the currently-implemented bits to CR we
have a list of things[3] that I'd love to tackle for a next version, and
events are already on that list.
Thanks again,
-Ted
1.
http://dxr.mozilla.org/mozilla-central/source/dom/webidl/GamepadButtonEvent.webidl
2.
http://dxr.mozilla.org/mozilla-central/source/dom/webidl/GamepadAxisMoveEvent.webidl
3. https://www.w3.org/wiki/Webapps/GamepadFeatures
[gamepad] Add an event-based input mechanism
Just as I mentioned in my previous email to this list, I recently was asked to review the Gamepad API draft specification. My background is games though I've done some scientific computing with alternate input devices too. http://chadaustin.me/2014/10/the-gamepad-api/ I'd like to make a second proposed change to the gamepad API, an event-based mechanism for receiving button and axis changes. The full rationale is explained in the linked article, but the summary is: 1) an event-based API entirely avoids the issue of missed button presses 2) event-based APIs don't require non-animating web pages to use requestAnimationFrame just to poll gamepad state 3) an event-based API could (and should!) give access to high-precision event timing information for use in gesture recognition and scientific computing 4) event-based APIs can reduce processing latency when a button changes state rapidly in low-frame-rate situations -- Chad Austin http://chadaustin.me
Re: [gamepad] Add an event-based input mechanism
Note that events for axis input can (when wrongly handled) lead to undesirable behavior. For instance, suppose you have a 2-axis input you use to plot a line on screen. If you poll the positions and then draw a line from the last position to the current position, you will get a smooth line. However if you receive events for axes, each arriving separately, and use each to plot a line, you will get a stepped/stairs line. If nothing but an event based mechanism is present, this would force an author to catch all axes events and collate them when no more events are queued. That'd require knowing when are no more events coming, which cannot be done in a callback based mechanism (as the event queue can't be queried). It's conceivable that some use-cases of buttons can run into similar scenarios (combos and whatnot). Although in these cases, a developer could probably keep track of the pressed buttons themselves. However, this means that not only button presses have to be provided, but also button releases, such that combos could be reliably detected by the developer. On Mon, Oct 13, 2014 at 9:03 AM, Chad Austin caus...@gmail.com wrote: Just as I mentioned in my previous email to this list, I recently was asked to review the Gamepad API draft specification. My background is games though I've done some scientific computing with alternate input devices too. http://chadaustin.me/2014/10/the-gamepad-api/ I'd like to make a second proposed change to the gamepad API, an event-based mechanism for receiving button and axis changes. The full rationale is explained in the linked article, but the summary is: 1) an event-based API entirely avoids the issue of missed button presses 2) event-based APIs don't require non-animating web pages to use requestAnimationFrame just to poll gamepad state 3) an event-based API could (and should!) give access to high-precision event timing information for use in gesture recognition and scientific computing 4) event-based APIs can reduce processing latency when a button changes state rapidly in low-frame-rate situations -- Chad Austin http://chadaustin.me
Re: [gamepad] Add an event-based input mechanism
On Mon, Oct 13, 2014 at 1:06 AM, Florian Bösch pya...@gmail.com wrote: Note that events for axis input can (when wrongly handled) lead to undesirable behavior. For instance, suppose you have a 2-axis input you use to plot a line on screen. If you poll the positions and then draw a line from the last position to the current position, you will get a smooth line. However if you receive events for axes, each arriving separately, and use each to plot a line, you will get a stepped/stairs line. If nothing but an event based mechanism is present, this would force an author to catch all axes events and collate them when no more events are queued. That'd require knowing when are no more events coming, which cannot be done in a callback based mechanism (as the event queue can't be queried). You are absolutely correct, and I did not necessarily mean gamepad events should look like onmousemove or onkeydown. I was imagining an event more like device has new data, after which a non-empty list of events would be available from the device. Presumably, events in said list can be coalesced to fit within a fixed buffer size if necessary. On the specific use case of drawing a smooth line from rough axis input, an appropriate smoothing algorithm should not rely on polling frequency -- especially requestAnimationFrame frequency -- but instead should generate the smooth curve (or sequence of line segments or whatever) from high-resolution event timing information if possible. Of course, this is where the discussion starts to approach the intersection of how humans perceive input and output, and why mice are sampled at hundreds of Hz rather than the 60 Hz of requestAnimationFrame. It's conceivable that some use-cases of buttons can run into similar scenarios (combos and whatnot). Although in these cases, a developer could probably keep track of the pressed buttons themselves. However, this means that not only button presses have to be provided, but also button releases, such that combos could be reliably detected by the developer. Yes, definitely. Button up is as important as button down.
