- From: Scott Graham <scottmg@chromium.org>
- Date: Wed, 2 May 2012 21:32:07 -0700
- To: Rick Waldron <waldron.rick@gmail.com>
- Cc: olli@pettay.fi, Webapps WG <public-webapps@w3.org>
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