Re: [gamepad] Add an event-based input mechanism

On Mon, Oct 13, 2014 at 1:06 AM, Florian Bösch <pyalot@gmail.com> wrote:

> Note that events for axis input can (when wrongly handled) lead to
> undesirable behavior. For instance, suppose you have a 2-axis input you use
> to plot a line on screen. If you poll the positions and then draw a line
> from the last position to the current position, you will get a smooth line.
> However if you receive events for axes, each arriving separately, and use
> each to plot a line, you will get a stepped/stairs line.
>
> If nothing but an event based mechanism is present, this would force an
> author to catch all axes events and collate them when no more events are
> queued. That'd require knowing "when are no more events coming", which
> cannot be done in a callback based mechanism (as the event queue can't be
> queried).
>

You are absolutely correct, and I did not necessarily mean gamepad events
should look like onmousemove or onkeydown.

I was imagining an event more like "device has new data", after which a
non-empty list of events would be available from the device.  Presumably,
events in said list can be coalesced to fit within a fixed buffer size if
necessary.

On the specific use case of drawing a smooth line from rough axis input, an
appropriate smoothing algorithm should not rely on polling frequency --
especially requestAnimationFrame frequency -- but instead should generate
the smooth curve (or sequence of line segments or whatever) from
high-resolution event timing information if possible.  Of course, this is
where the discussion starts to approach the intersection of how humans
perceive input and output, and why mice are sampled at hundreds of Hz
rather than the 60 Hz of requestAnimationFrame.

It's conceivable that some use-cases of buttons can run into similar
> scenarios (combos and whatnot). Although in these cases, a developer could
> probably keep track of the pressed buttons themselves. However, this means
> that not only button presses have to be provided, but also button releases,
> such that combos could be reliably detected by the developer.
>

Yes, definitely.  Button up is as important as button down.