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
Re: [gamepad] Add an event-based input mechanism
On Mon, Oct 13, 2014 at 1:06 AM, Florian Bösch 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.
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 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 >