Inking out a PenObserver, was Re: GamepadObserver (ie. MutationObserver + Gamepad)

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

Received on Friday, 4 May 2012 09:18:40 UTC