- 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