Re: [w3c/gamepad] Should spec a buffering/refresh interval model of gamepad data? (#22)

See inline.

On Thu, May 5, 2016 at 1:42 PM, juj <notifications@github.com> wrote:

> Thanks for the great comments! I agree that any "superhuman" button
> presses that only occur for a single digit millisecond duration are of not
> concern. Not sure whether the OS itself would be registering these either.
>
> Although the "all these thinking assumes that our polling is happening at
> 60Hz no matter what and the same about firing rAF which might always be the
> case (but we should be close to that for quality gaming experience
> anyway)." thought could be read a bit in a all bets are off type of
> scenario for the Gamepad API if one doesn't have 60fps. I think it's rather
> the hiccup/GC stutter cases and slow frame rates exactly that are the
> important consideration. We would not want to miss button presses in the
> event that for example the JS garbage collector decided to take a 500msec
> pause in a critical moment in a game.
>

​It's not clear to me that you really better off processing those events
after the fact. In case of missed frames users typically keep pushing the
button. Like you are in a racing game pushing the gas, nothing happens, you
will keep pushing it. Now if the game buffers it up it might get even
worse, you end up accelerating too much so you lose control and start
yelling at your browser. :) I don't have a lot of game development
experience so I might not take all details into account here but my gut
feeling is that if you miss a frame it's better to ignore the input from
that frame too.
​


> I'm leaning to thinking that perhaps Gamepad API should add an event model
> which ensures best possible promise about no lost events. With this, if the
> OS buffers up gamepad events, then these could be naturally delivered. And
> .getGamepads() could always return the most recent data that browser has,
> which would be good for sampling analog signals when only most recent
> signal value is of interest. (e.g. racing car throttle position).
>
> I would dislike having a snapshot model spec which would go and specify
> actual millisecond intervals when polling occurs or anything like that.
> That would feel brittle.
>
> On the topic of theoretical vs concrete, and the superhuman question
> aside, the question of whether the second code snippet above has a danger
> of losing presses is a concrete issue. This is more rather a question of
> whether a browser implementation might be using a separate thread to
> receive gamepad api messages, and the polled data could change mid-flight
> when JavaScript code is executing. That could make the two code snippets
> behave differently. Does the spec (intend to) allow that?
>

​With the chromium implementation it's definitely not changing on the fly.
If the browser have a polling thread - which chromium has - than it has to
take care of synchronization, I'm sure the spec doesn't intend to allow the
luck of that. Also I don't think the spec has to be explicit on this, it's
beyond the scope of a spec to define every possible implementation pitfalls.



> —
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub
> <https://github.com/w3c/gamepad/issues/22#issuecomment-217222576>
>


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/22#issuecomment-217605973