- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 03 Aug 2012 10:40:37 -0700
- To: Florian Bösch <pyalot@gmail.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <501C0D15.5060005@jumis.com>
On 8/3/2012 10:33 AM, Florian Bösch wrote:
> On Fri, Aug 3, 2012 at 7:21 PM, Charles Pritchard <chuck@jumis.com
> <mailto:chuck@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
Received on Friday, 3 August 2012 17:40:55 UTC