There's two aspects that should not be overlooked.
1. Some events only make sense in unison. For instance the input of a
2-axis knob. On many OS implementations, change events for each axis arrive
separately in short succession. However to an application programmer,
getting first the
On 4/30/2014 12:21 AM, Glenn Maynard wrote:
My original prototype provided the events mentioned above. The
feedback I received was overwhelmingly in favor of a polling API
instead[3]. I decided to go ahead with that (actually Scott beat
me to the punch and implemented that in
On 4/29/2014 10:39 AM, Ted Mielczarek wrote:
The only major issue that needs to be fixed in the Gamepad API spec
currently is the liveness of Gamepad objects[1].
After reading through the discussion here I'm leaning towards specifying
the snapshot behavior that Chrome implements. Regardless of
On Wed, Apr 30, 2014 at 5:58 AM, Ted Mielczarek t...@mozilla.com wrote:
Yes, it's true. In any event, this is going a bit afield. We're not going
to spec events for the first version of the spec.
Examining the features that each design would make easier or harder isn't
afield.
On Wed, Apr
On Wed, Apr 30, 2014 at 12:21 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek t...@mozilla.com wrote:
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most
From: Ted Mielczarek t...@mozilla.com
Does anyone have any feedback on which of these seems more natural? Is there
any precedent in the web platform to prefer one approach over the other?
If the snapshot approach is chosen, I think it would be best to rename the
Gamepad interface to
On Tue, Apr 29, 2014 at 4:24 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
If the snapshot approach is chosen, I think it would be best to rename the
Gamepad interface to GamepadSnapshot. Without that change, the live approach
seems a lot more natural.
DOM nodes are live. That is,
On 4/29/14, 11:32 AM, Anne van Kesteren wrote:
I think the main problem with making a Gamepad live is that the
lifetime of the object has to be lifetime of the associated global.
Otherwise GC can be observed through expandos.
For what it's worth, the way Gecko implements this is by setting up
Boris Zbarsky wrote:
For what it's worth, the way Gecko implements this is by setting up
that lifetime guarantee only when an expando is added to the object
(or some other things, like use as a WeakMap key, happen). Until then
we allow it to be GCed.
What do other engines do in general?
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the question? Thanks.
(Yes, I found https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.htmlby
googling. It's not what I need.)
On Tue, Apr 29, 2014 at 10:16 AM, Brendan Eich
I don't think that API design should be driven by implementation details,
but it may be useful to provide some background on Chrome's Gamepad
implementation here:
The current polling-only API Chrome uses is largely due to practicality
with the multiprocess architecture. The gamepad data is
On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
wrote:
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the question? Thanks.
The Gamepad API returns an array of Gamepad state objects when you call
getGamepads(), like so:
How would either make GC observable?
On Tue, Apr 29, 2014 at 10:45 AM, Brandon Jones bajo...@google.com wrote:
On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
wrote:
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the
On Tue, Apr 29, 2014 at 10:39 AM, Ted Mielczarek t...@mozilla.com wrote:
The only major issue that needs to be fixed in the Gamepad API spec
currently is the liveness of Gamepad objects[1].
Currently this is implemented differently in Firefox and Chrome--Firefox
uses live Gamepad objects, in
On Tue, Apr 29, 2014 at 1:45 PM, Brandon Jones bajo...@google.com wrote:
On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
wrote:
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the question? Thanks.
The Gamepad API
On 4/29/14, 1:46 PM, Mark S. Miller wrote:
How would either make GC observable?
Consider the following code:
navigator.getGamepads()[0].foo = 5;
var intervals = 0;
var id = setInterval(function() {
++intervals;
if (navigator.getGamepads()[0].foo != 5) {
alert(What happened
On 4/29/2014 1:34 PM, Brandon Jones wrote:
I don't think that API design should be driven by implementation
details, but it may be useful to provide some background on Chrome's
Gamepad implementation here:
The current polling-only API Chrome uses is largely due to
practicality with the
On Tue, Apr 29, 2014 at 11:07 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/29/14, 1:46 PM, Mark S. Miller wrote:
How would either make GC observable?
Consider the following code:
navigator.getGamepads()[0].foo = 5;
var intervals = 0;
var id = setInterval(function() {
I think both semantics are workable. I'd likely prefer the gamepad state to
be immutable from JS, because assigning state there is smelly. I'd also
prefer the option that incurs less GC overhead if possible. Beyond that, I
just think the implementations should be semantically and symbolically
On Tue, Apr 29, 2014 at 3:27 PM, Florian Bösch pya...@gmail.com wrote:
I think both semantics are workable. I'd likely prefer the gamepad state
to be immutable from JS, because assigning state there is smelly.
Yes, there should be no way for user code to directly alter the value of
properties
Gamepad objects should definitely be a snapshot. Otherwise, change events
could only expose the most recent state of the gamepad. For example, if
the user presses a button and then releases it very quickly (before the
down press gets handled by script), and you fire two change events, the
script
If it were my call I'd vote for gamepad objects being snapshots simply
because it will add some additional overhead to make them live and it
avoid concerns about observing GC, but I don't really object to either
design.
Anne mentioned the observable GC concern, he said the spec should
On Tue Apr 29 2014 at 4:28:31 PM, Glenn Maynard gl...@zewt.org wrote:
(That said, I'm confused--where's the event to tell the user that the
gamepad has changed? Surely this API doesn't require the developer to
poll, which would lose inputs at the slightest GC skip and could never give
high
On Tue, Apr 29, 2014 at 6:42 PM, Brandon Jones bajo...@google.com wrote:
On Tue Apr 29 2014 at 4:28:31 PM, Glenn Maynard gl...@zewt.org wrote:
(That said, I'm confused--where's the event to tell the user that the
gamepad has changed? Surely this API doesn't require the developer to
poll,
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example, if the user presses a button and then releases it very
quickly (before the down press gets handled by
On 4/29/2014 7:35 PM, Oren Freiberg wrote:
Originally I was leaning towards live model but I am now leaning towards a
snapshot model being the better option. We also found that there was added
overhead with making the values live. Having had a few developers play around
with both the idea
On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change events
could only expose the most recent state of the gamepad. For example, if
the user presses a button and then releases it very quickly (before the
down
On Tue, Apr 29, 2014 at 9:38 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example,
On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek t...@mozilla.com wrote:
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example, if the user presses a button
29 matches
Mail list logo
