Re: [Gamepad] Liveness of Gamepad objects

On Wed, Apr 30, 2014 at 12:21 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek <ted@mozilla.com> wrote:
>
>>  On 4/29/2014 7:28 PM, Glenn Maynard wrote:
>>
>>   Gamepad objects should definitely be a snapshot.  Otherwise, change
>> events could only expose the most recent state of the gamepad.  For
>> example, if the user presses a button and then releases it very quickly
>> (before the down press gets handled by script), and you fire two change
>> events, the script would never see the buttons as pressed.
>>
>>
>> This is a good point--if we have live objects then if we do implement
>> change events we'd need to store the state elsewhere. Firefox has
>> gamepadbutton{press,release} events and gamepadaxismove events[1][2]
>> (behind a pref), they actually do this already but it's not fantastic.
>>
>
> There should simply be a "change" event, which is fired when any property
> changes.  (Some rate clamping might be needed for analog inputs, which
> could change very quickly, but that's an implementation detail.)
>
>  My original prototype provided the events mentioned above. The feedback I
>> received was overwhelmingly in favor of a polling API instead[3]. I decided
>> to go ahead with that (actually Scott beat me to the punch and implemented
>> that in Chrome first), figuring we could always spec events in a future
>> revision.
>>
>
> (Please try to direct conversations here or to the whatwg list, so
> everyone has a chance to participate...)
>
> Supporting polling is a separate issue from whether the Gamepad interface
> is live or a snapshot.  You definitely want to be able to retrieve a
> snapshot of the current state, and as long as you can do that you
> automatically support polling.
>
> That is, users can either use polling:
>
> onRequestAnimationFrame = function() {
>     // Once we create this, it never changes, so we can compare it the
> next time around when it becomes lastGamepadState.
>     var gamepadState = navigator.getGamepads();
>
>     // Find differences between lastGamepadState and gamepadState and act
> on them:
>     for(var i = 0; i < gamepadState.length; ++i)
>         processInput(gamepadState[i], lastGamepadState[i]);
>
>     // Save the current state, for comparison during the next frame.
>     lastGamepadState = gamepadState;
> }
>
> or events:
>
> navigator.onGamepadChange = function(e) {
>     var gamepadState = e.state;
>     processInput(e.gamepadIndex, gamepadState, lastGamepadState);
>     lastGamepadState[e.gamepadIndex] = gamepadState;
> }
>
>
This is exactly the semantics I described here
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0266.html,
with the exception that the Gamepad object is live and the change event
states are "snapshots".


Something else to consider: how does a Gamepad object behave with
Object.observe?

var gamepads = navigator.getGamepads();

Object.observe(gamepads[0], function(changeRecords) {
  ...
});


Presumably the "live" object design will work as expected, invoking the
observe handler at the end of each processing turn "microtask"
(changeRecords will always include the previous and current values), and
the "snapshot" does not.


Rick