On 8/3/2012 10:33 AM, Florian Bösch wrote:
On Fri, Aug 3, 2012 at 7:21 PM, Charles Pritchard <ch...@jumis.com
<mailto:ch...@jumis.com>> wrote:
What kind of correlated events are you thinking of?
For instance most tablet drivers deliver X/Y events separately. If you
processed those individually, fast brushstrokes would become
staircases. To avoid that, developers filter the queue and whenever
the see an X event (which always arrives before the Y event) they wait
for the Y event before correlating them to a "X+Y" event.
I was not aware of that. My experience comes mostly from the Wacom
plugins which handle that work before delivering.
It seems like this is something the implementer should handle;
delivering the full event to the developer.
http://www.wacomeng.com/web/WebPluginReleaseNotes.htm#_Toc324315286
They've done some touch event work as well:
http://www.wacomeng.com/web/WebPluginTouchAPI.htm
Some of this was discussed as part of the Sensor API proposal. It
seems that work is being shuffled into a web intents mechanism.
I've not yet experimented with high volume/precision data over
postMessage.
No idea what the intents is, but usually the "intend" in processing
events is implemented by the developer who processes the events, so
other than his application code, no further complication is required.
We Intents is a mechanism for posting/grabbing data as well as discovery.
http://webintents.org/
In intents, you might have an <iframe> which then runs the <object>
attaching to Wacom's plugin.
All websites would simply trigger an intent, such as asking for pen
data; they would not need to worry about opening an iframe or object tag.
I've not gotten to it, but I'll get a demo posted one of these days.
Item 2 is fun stuff, but at present, only the touch API has touched
on the concept of multiple pointers.
This product line http://www.wacom.com/en/Products/Intuos.aspx is both
a multitouch surface and pen input (although not both at the same
time). http://www.wacom.com/en/Products/Intuos.aspx
I suspect however that the "not at the same time" aspect isn't a
hardware or even driver limitation, but rather results from the
compulsive need of applications/OSes to pretend touches and pens are
core pointers, and since there can't be two pointers... If a suitable
capture mode where implemented, I don't think simultaneous touches and
pen strokes would present a problem (and they'd certainly be fun to use).
I agree; but our event infrastructure for the web isn't quite ready for
two mouse pointers to run at the same time over a webpage.
It's something I'd like to see addressed.
Item 1 we can do that with pointer lock.
You do bring up a good point, if the web platform did
concurrent/multiple pointer devices, it'd be nice if it the
pointer lock API was aware of that situation.
As I understand it, the new release of Windows does have mature
support for multiple pointers. Support has been available for some
time.
The web platform is falling a bit behind in this area. Of course,
they haven't caught up with pen events yet and those have been
around for decades.
I suspect the affine transform is something that the author ought
to be processing from nice raw data.
They can use something like the CSSMatrix() object or other maths
to do transforms.
With a complex Canvas drawing surface, I've had to do about 3
levels of transforms anyway.
onmightypenevent(e) { coordsForNextStep =
myMatrix.transform(e.arbitraryX, e.arbitraryY); };
Correct, you can leave it up to the developer and just engage
pointerlock. However there's a snag with that.
- You need to have fullscreen to get pointerlock
- You might desire to get pointerlock on the drawing surface, but not
engage fullscreen
- You'll want to engage pointerlock for more direct interaction, yet
disengage it again for interaction with interface elements in the DOM.
Everytime you engage/disengage it there's dialog boxes and whatnot.
All good points.
-Charles
