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

Well, how about just events for the pressable buttons then? That would
alleviate most of my concerns with the polling model, and I think you're
right it's harder to apply it to axes given that there are effectively two
inputs working simultaneously.

Ashley


On 9 April 2015 at 22:29, Florian Bösch <pyalot@gmail.com> wrote:

> 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
>>>
>>>
>>>
>>
>