On 8/3/2012 10:09 AM, Florian Bösch wrote:
On Fri, Aug 3, 2012 at 6:54 PM, Charles Pritchard <ch...@jumis.com
<mailto:ch...@jumis.com>> wrote:
As I understand it, the browsers have mature event queues; and
everything comes with a timestamp.
We've got requestAnimationFrame as our primary loop for processing
the queue.
To clear a queue (so to speak), I believe one simple removes any
associated handlers.
Yeah but that's not how it should work.
- Assuming requestAnimationFrame might be wrong in case that other
events are used to refresh either logic or simulation (such as when
redraws only happen upon input)
It's a complex wait mechanism:
onload -> onmousemove -> requestAnimationFrame [until idle] -> onmousemove.
Until we worked with high resolution events, we simply hooked into
onmousemove. At some point, it became clear that was inefficient
and we tested out setTimeout loops (rAF was not available at the time).
- Dispatching events individually makes it difficult to work out
correlated events, and since the device landscape changes constantly,
it'd be easier to adopt new devices for developers if they could do
their own correllation according to their needs. For that they need
the buffer of queued events to work trough them.
What kind of correlated events are you thinking of?
- Depending on the use there's a differing "granularities" that a
developer might want to implement. This is usually done by filtering
the queue according to the applications needs, if receiving events
individually, that'd just lead to the developer re-implementing the
queue so he can filter it at the appropriate time.
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.
Are there any times when mouse emulation is not executed with a pen?
As much as I've used my pen, it always "moves the mouse".
Capture to area is something that's being handled for pointer
events. I recently read that support for mouse capture is being
contributed to webkit; it's at least, being actively authored.
The capture model is based on the full screen request model.
The mouse emulation mode is appropriate when: 1) the tablet is used to
interact with a larger area containing interface elements AND 2) it is
used singularly AND 3) the screen dimensions match the tablet dimensions.
It is not appropriate when 1) the tablet is used to interact with a
limited area (such as a drawing surface) exclusively OR 2) the tablet
is used ambidexterity in conjunction with other pointing devices
and/or multiple pens OR 3) the screen dimensions do not match the
tablet dimensions
Item 3 seems a matter of configuration, I don't think we have anything
to do on that one.
Item 2 is fun stuff, but at present, only the touch API has touched on
the concept of multiple pointers.
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.
Regarding #1, this situation arises naturally when drawing is engaged
with the limited area, but the area on screen is considerably smaller
than the screen, which would result in the artist having to rely on a
tiny area on his large tablet to engage in drawing, while most of the
tablets surface area lies bare unused. GIMP implements capturing modes
to drawing area, although the implementation is lacking and it cannot
be switched seamlessly. Photoshop implements capture to area which can
be switched seamlessly between mouse control and drawing utensil on
surface control.
The analogy to pointer lock is fitting, however the conflation of
fullscreen+pointerlock is not appropriate and it is lacking the affine
transform aspect of a capture to area mode.
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); };