Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Wed, May 2, 2012 at 6:09 PM, Rick Waldron <waldron.rick@gmail.com> wrote:
>
>
> On Wed, May 2, 2012 at 7:01 PM, Scott Graham <scottmg@chromium.org> wrote:
>>
>> On Wed, May 2, 2012 at 3:12 PM, Rick Waldron <waldron.rick@gmail.com>
>> wrote:
>> > On Wed, May 2, 2012 at 5:54 PM, Olli Pettay <Olli.Pettay@helsinki.fi>
>> > wrote:
>> >>
>> >> On 05/03/2012 12:48 AM, Rick Waldron wrote:
>> >>>
>> >>> Instead of traditional DOM events being used for Other Events[1], and
>> >>> considering the high frequency of Gamepad state changes, it might make
>> >>> sense to provide an API similar to MutationObserver, where a
>> >>> MutationRecord is created that has snapshots of current and previous
>> >>> states of axes or buttons...
>> >>>
>> >>>
>> >>> This is entirely hypothetical:
>> >>>
>> >>> (new GamepadObserver(function(mutations) {
>> >>>
>> >>>   console.log( mutations );
>> >>>   /*
>> >>>   {
>> >>>     previousState: {
>> >>>       readonly attribute string       id;
>> >>>       readonly attribute long         index;
>> >>>       readonly attribute DOMTimeStamp timestamp;
>> >>>
>> >>> // Either or both of the following, bases on the options list
>> >>>
>> >>>       readonly attribute float[]      axes;
>> >>>       readonly attribute float[]      buttons;
>> >>>     }
>> >>>
>> >>>     currentState: {
>> >>>       readonly attribute string       id;
>> >>>       readonly attribute long         index;
>> >>>       readonly attribute DOMTimeStamp timestamp;
>> >>>
>> >>> // Either or both of the following, bases on the options list
>> >>>
>> >>>       readonly attribute float[]      axes;
>> >>>       readonly attribute float[]      buttons;
>> >>>     }
>> >>>   }
>> >>>   */
>> >>> })).observe(navigator.gamepads[0], { axesList: true });
>> >>>
>> >>> //  axesList, buttonsList
>> >>>
>> >>> [1]
>> >>> http://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html#other-events
>> >>>
>> >>>
>> >>> Rick
>> >>
>> >>
>> >>
>> >> no need for this kind of thing. Gamepad data is external, so
>> >> dispatching
>> >> events is better. The event can of course keep
>> >> a list of changes since the previous event dispatch.
>> >
>> >
>> > I had originally argued for an event, though met with resistance. The
>> > reasoning was that gamepad state changes are far too high resolution
>> > which
>> > would result in high event dispatch volume.
>> >
>> > Is there documented discussion surrounding the return to an event being
>> > desirable?
>>
>> I'm not aware of any pro/against discussion on that other than the
>> Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=604039. I
>> don't think there's consensus on that point yet.
>>
>
> Weird, because you posted
> this: https://docs.google.com/document/d/1atsxnstVybfovkX_f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en_US
>
> here: https://bugzilla.mozilla.org/show_bug.cgi?id=604039#c40

I'm not sure what you mean. It is my opinion is that it would be
inefficient to spam 50+ button and axis events multiplied by (say) 4
devices @ 60Hz, which is why I've been pursuing the design of a
polling API. So, though what you quoted was written a while back, it
seems to still represent my opinion pretty accurately.

I'm not sure if everyone agrees with me on that though, which is why I
said I didn't think there was a consensus. I believe Mozilla's
vendor-prefixed implementation includes some of those type of events,
so perhaps we will soon have more empirical data on the subject.

>
> In which you state:
>
>> The current proposal for accessing Joysticks from Mozilla is an
>> event-based one, mirroring keyboard and mouse input.
>> https://wiki.mozilla.org/JoystickAPI
>> At 60fps, with all the of the analog buttons, triggers, vibration,
>> gyroscope on modern game pad (PS3, Xbox 360, and others) there will easily
>> be many events within each 16ms frame.
>> With so many events, it’s both inefficient, as many events will only be
>> handled in order to update the “current state”, and complex to correctly
>> maintain and update the state, which will have to be written in every
>> application.
>> On the positive side, events and polling are not mutually exclusive. While
>> it seems like the primary use-case for gamepad input is for games, which
>> would prefer polling, there may be some uses where the event-based is
>> better, say for using the gamepad as an input device to advance frames in a
>> presentation.
>
>
>
> Rick
>
>
>>
>> The observer ability of filtering to desired-only seems interesting. I
>> guess it might get complex if it was to be filtered more finely than
>> just axesList/buttonsList.
>>
>>
>>
>> >
>> > Thanks for your time.
>> >
>> >
>> > Rick
>> >
>> >
>> >>
>> >>
>> >>
>> >>
>> >> -Olli
>> >>
>> >
>
>

Received on Thursday, 3 May 2012 04:32:37 UTC