Re: PSA: publishing new WD of Gamepad on April 14

The polling model for axes has a significant advantage as I'll illustrate.

Suppose you're steering a cursor of some kind in 2 dimensions. That cursor
would also draw a trail/line whatever. Here's what happens if you apply
this logic on events per axis: You get a staircase. Why? Because the X-axis
event arrives, you move the cursor to the side, draw a line, then the
Y-axis event arrives, you move the cursor up, you draw a line -> a
staircase.

If you poll the position of all axes, this effect will not happen, you draw
the correct diagonal line.

In order to emulate the correct behavior with axis events, you'd have to
capture all events, and keep the value of axes separately so you can draw
to the appropriate position. But that can't work, because you don't have
control over the polling behavior, that is, you don't know when all events
are processed.

This problem is broadly in the category of correlated event updates, and
polling the status (of at least all axes) at a given time solves this
nicely. So this functionality should not go away. In fact, it could be well
argued that even if you do dispatch events (where they're primarily useful
as in buttons), you should still be able to initiate the poll as for when
all events are delivered (instead of having them delivered at an
unopportune/uncontrolled time).

The main drawback of not having events isn't that you'll have to keep the
state separately. That's easy. The main problem is that because multiple
events make up one final state, you can miss things, such as a button press.

On Thu, Apr 9, 2015 at 11:15 PM, Ashley Gullen <ashley@scirra.com> wrote:

> Why doesn't the Gamepad API fire events for button pushes or axis
> movements? For example when pressing a mouse button or moving the mouse the
> browser fires "mousedown" and "mousemove". The Gamepad API however requires
> you to passively poll the state regularly (probably in rAF) and look for
> changes yourself. Why does it not fire events like "gamepadbuttondown" or
> "gamepadaxischange"? This would have a few advantages:
>
> - it would be consistent with the way all other input events are handled
> on the web platform
> - it is easier to program for. As it stands since there is nothing like a
> "gamepadbuttondown" event, so if you want one, you have to implement it
> yourself by polling the state, keeping the previous polled state, and
> comparing the differences looking for a previously up but currently down
> state and then run your handler.
> - browsers have a couple of important features that can only work in a
> "user gesture", such as opening a popup window, copying to the clipboard,
> or - critically for games! - starting audio (or video) playback on mobile.
> Since the Gamepad API does not fire events, this does not integrate nicely
> with the existing "user gesture" model, and therefore currently no browser
> allows these features to be triggered by gamepad input. Considering the use
> case of a gamepad controlling a browser game on a tablet, it's pretty
> embarrassing that you can't play audio without resorting to some other kind
> of input, like regularly leaning forwards to touch the screen.
>
> This could involve significant changes to the spec, but I think it's
> necessary. It looks a bit like a first draft that never got reconsidered.
>
> Ashley Gullen
> Scirra.com
>
>
>
> On 9 April 2015 at 12:52, Arthur Barstow <art.barstow@gmail.com> wrote:
>
>> Hi All,
>>
>> A new Working Draft publication of Gamepad is planned for April 14 using
>> the following version as the basis:
>>
>>   <https://w3c.github.io/gamepad/publish/gamepad.html>
>>
>> If anyone has any major concerns about this, please reply right away.
>>
>> A few notes about this spec:
>>
>> * This spec is now using Github <https://github.com/w3c/gamepad> and the
>> ED is <https://w3c.github.io/gamepad/gamepad.html>. PRs are welcome and
>> encouraged.
>>
>> * The permissions of the spec's now obsolete Hg repository will be set to
>> read-only.
>>
>> * After Ted copies the open Bugzilla bugs to Github, the spec's Bugzilla
>> component will be marked `Historical` and set to read-only.
>>
>> -Thanks, ArtB
>>
>>
>>
>