Re: GamepadObserver (ie. MutationObserver + Gamepad)

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

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