W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: GamepadObserver (ie. MutationObserver + Gamepad)

From: Scott Graham <scottmg@chromium.org>
Date: Wed, 2 May 2012 16:01:49 -0700
Message-ID: <CANHK6RZaJLozj3ROzKs8RhOK4gsWQSq=XKZB9pN0A==bN-PbXw@mail.gmail.com>
To: Rick Waldron <waldron.rick@gmail.com>
Cc: olli@pettay.fi, Webapps WG <public-webapps@w3.org>
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.

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 Wednesday, 2 May 2012 23:02:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT