Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 4:24 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> 5ms is quite low when the aim is 60Hz updates... but with
> incremental/generational GCs 5ms sounds very much possible.
>

5ms is an *eternity* when you're aiming for 60 FPS, where you only have
16.6ms per frame to play with.  That's 30% of your CPU budget just for
memory management.  It doesn't matter if it's 5ms every 100 frames, since
it's the worst case you have to optimize for.  (I've spent a lot of time
optimizing non-web games to stay at 60 FPS, and it's a battle of
microseconds, optimizing away .1ms here and .2ms there, so calling 5ms
"quite low" is a bit troubling.)

But like I said, I think we should punt on this for now; if it turns out to
be needed, a GC-friendly abstraction can always be thinly layered on top of
this one.  (I have a partially-formed mental picture of how that could
work, but I really don't want to sidetrack the thread with that.  I'm not
convinced that playing GC whack-a-mole is a practical solution to this,
though.)

On Sat, Aug 4, 2012 at 12:25 PM, Florian Bösch <pyalot@gmail.com> wrote:

> - A mixed model is where an axis is used with tresholds (like say a weapon
> trigger with the index finger). A miss is not bad, but response accuracy
> will improve from getting the event as close to the threshold as possible.
> So this would inform the API of its thresholds for this axis, so events can
> be issued when the high frequency polling detects the axis going over the
> it.
>

I'd suggest also putting this off until later--it can be added if it turns
out to be needed in practice.  (You're describing using analog inputs as
binary inputs, and there are a few ways to do that, but I'd lean towards
not complicating the API with it at the start.)

(I think we should let the thread sit for a while until Scott gets back
around to it, so the discussion doesn't get too far ahead of itself.)

-- 
Glenn Maynard