On 8/3/2012 3:54 AM, Florian Bösch wrote:
On Fri, Aug 3, 2012 at 8:09 AM, Charles Pritchard <[email protected]
<mailto:[email protected]>> wrote:
Touch events v2 has some properties, such as pressure
Although lacking most other properties (Z, tilt, rotation etc.)
Yes: so far I've not been able to garner interest in Pen events.
The touch events v2 properties are really just a stub, a reminder that
something ought to be done.
I was also able to get a stub put into the SVG2 planning documents.
That's the best I've been able to get, as vendors are rather luke-warm
on pen events.
InkML covers the full serialization of captured data.
It looked fairly complete, though I was missing the pen type/ID
property. Also it's not clear to me how this would map to JS events
required when using the pen input for things like WebGL.
http://www.w3.org/TR/InkML/#inkSource
As well as the simpler brush xml:id.
WebGL vectors map well to brush traces.
One would process a trace group into an int or float array then upload
that to webgl for rendering.
Or, one might use that array to render via Canvas 2d.
The issue is that we have no mechanism to actually capture high
resolution ink data.
The Gamepad API is the closest implementation in browsers (Chrome)
There's a few extra challenges like correlating inputs (X/Y) and
usually you'll want some capture mode (exclusive to area or mouse
emulation) switch, which the gamepad API does not cover afaik.
They've also hit sampling issues: initial drafts and implementations
worked with polling.
It seems that event callbacks are more appropriate.
My main issue with plugins and ink, and serial polling, is that I lose
data when I render: I can either have high quality input, and poor
immediate rendering,
or high quality rendering, but lose a lot of accuracy in the data stream.
and Wacom's Air implementation one of the closest in an HTML
environment.
You mean Adobe Air?
Wacom made some plugin items which run on Adobe's Air. They have
onpenpressure events, for instance.
-Charles
