W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Drawing Tablets

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 03 Aug 2012 10:40:37 -0700
Message-ID: <501C0D15.5060005@jumis.com>
To: Florian Bösch <pyalot@gmail.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT