Glenn, all of your points apply well to pressure sensitive pen input.
Pen vendors are not on the list, but their devices are quite similar.
I've changed the subject line and my responses are to your gamepad notes
in respect to their application to pen input.
Pen input in this case is pressure sensitive input with high sensitivity
to time, pressure and coordinates, with a sample rate faster than 60hz.
Pen devices are commonly connected via USB.
The Gamepad API is an experimental API which deals with similar device
characteristics. Pen vendors are not active with the W3C though the
InkML specification did make it into recommendation status.
On 5/3/2012 9:14 PM, Glenn Maynard wrote:
Here are some piecemeal thoughts on the subject of gamepads and the
"gamepad" spec. I havn't closely followed earlier discussions (and
there don't seem to have been any in a while), so much of this may
have been covered before.
- It should be possible to tell what's changed, not just the current
state of the device. Needing to compare each piece of input to the
previous state is cumbersome.
There's a variety of options that may not ever change. Some devices may
simply not support the values. With pen, we've got items like azimuth
and altitude. Few pens support it.
As authors, we just ignore that input or do feature tests (if pressure
exists, and those metrics are still 0, then they're likely not supported).
- Native deadzone handling (by the OS or internally to the device) is
the only way to correctly handle deadzones when you don't have
intimate knowledge of the hardware. It should be explicitly (if
non-normatively) noted that native deadzone handling should be used
when available.
- It's very important that it's possible to receive gamepad data
without polling. We don't need more web pages running setTimeout(0)
loops as fast as browsers will let them, which is what it encourages.
Not all pages are based on a requestAnimationFrame loop.
Recently, I found a setTimeout(20ms, then rAF) to work reasonably well
for my little laptop. Any faster, and I lose more data points, and
slower and the lag [drawing to the screen] is disorienting.
That's just a subjective observation on a light-duty laptop with one
vendor, just using a track pad.
- An API that can only return the current state loses button presses
if they're released too quickly. It's common to press a button while
the UI thread is held up for one reason or another--and you also can't
assume that users can't press and release a button in under 16ms (they
can).
The rAF loop can in some circumstances "slow" the polling or otherwise
result in data loss.
It's a real pain. We get our best fidelity if the screen is empty and
we're not drawing. Once we start drawing, we're bound to lose some data.
- APIs like that also lose the *order* of button presses, when they're
pressed too quickly. (I've encountered this problem in my own
experience; it's definitely possible--it's not even particularly
hard--for a user to press two buttons in a specific order in under 16ms.)
My pen has two buttons in addition to two high sensitivity pressure
inputs. Wacom introduced "onpressurechange" events in their Flash SDL.
In some sense, it's an experimental plugin for WebKit as it runs in Air,
but it's really closer to the Flash side of things.
I'd suggest a halfway point between polling and events: a function to
retrieve a list of device changes since the last call, and an event
fired on the object the first time a new change is made. For example,
var gamepad = window.openGamepad(0);
gamepad.addEventListener("input", function(e) {
var changes = gamepad.readChanges();
}, false);
with changes being an array of objects, each object describing a
timestamped change of state, eg:
changes = [
{
button: 0,
state: 1.0,
lastState: 0.85,
timestamp: 1336102719319
}
]
At what point would we consider entries to be stale? Is that something
that should be a concern?
It'd take quite a lot of changes to be a problem.
As a security issue -- do we need to point out that two windows should
not have concurrent access to the same gamepad (such as applies to
keyboard and mouse)?
That's another issue I noticed with pen tablet plugins.
-Charles
