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

Re: GamepadObserver (ie. MutationObserver + Gamepad)

From: Rick Waldron <waldron.rick@gmail.com>
Date: Thu, 3 May 2012 14:09:48 -0400
Message-ID: <CAHfnhfpRgc1tTpxtNvLOUEOLziasXKXYzAB9BqYzdt-BVH32Kw@mail.gmail.com>
To: Scott Graham <scottmg@chromium.org>
Cc: olli@pettay.fi, Webapps WG <public-webapps@w3.org>
 snip


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


Just to be clear, I'm not trying to be aggressive or confrontational, but I
just reread my message from last night and realized it could easily be read
that way - apologies!  :)


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.


I agree with both arguments, because you're right: it's simply too much
volume. As for existing data or APIs, Microsoft's DirectInput API provides
both polling and event notifications.

Going back to the notes at
http://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html#other-events I'd
say the single event "gamepagechanged", where the event object has a
property describing the complete state of the gamepad, is more in line with
the DirectInput event system. Something like this would also make it easier
to detect multiple, sequentially and/or simultaneously changed states...

eg. press and hold B; while holding B, press A
(for the sake of example, the states will be HIGH and LOW, both start LOW)

Dispatch an event for the change of state on B. B set HIGH
Dispatch an event for the change of state on A. A set HIGH, B still HIGH

When the event is dispatched for the changed state of A, the handler
receives an event object that will show no change to the state of B since
it was set to HIGH.


With separate axis and button events, I dont think this could be reasonably
feasible.


Again, apologies for any perceived negative tone from earlier messages :)


Rick




[snip]
Received on Thursday, 3 May 2012 18:10:38 GMT

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