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 09:54:03 -0700
Message-ID: <501C022B.6060200@jumis.com>
To: Florian Bösch <pyalot@gmail.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 8/3/2012 9:46 AM, Florian Bösch wrote:
>
>     My main issue with plugins and ink, and serial polling, is that I
>     lose data when I render: I can either have high quality input, and
>     poor immediate rendering,
>     or high quality rendering, but lose a lot of accuracy in the data
>     stream.
>
> It's a well known problem for game applications, I'm a bit surprised 
> this wasn't done right from the start.
>
> 1) The host OS APIs support a hodgepodge of 
> polling/queing/selecting/events. Usually polling APIs require a very 
> high frequency of polling.
> 2) For this reason game related frameworks like SDL, pygame, pyglet 
> etc. abstract the underlying mechanism and fill event queues.
> 3) At user choosen intervals the queues events are dispatched by 
> either letting the user call a a) "get all events" function which 
> clears the queue and the user is responsible to work trough that queue 
> (SDL/pygame model) or b) by the framework dispatching events 
> individually at regular intervals (pyglet)
>
> In working with framework dispatched events I hit some snags (such as 
> when events that belong together are not correlated by the framework) 
> which renders some devices the framework hasn't been coded for 
> unusable (tablets for instance). I'd definitely prefer the flavor that 
> lets the user explicitly clear the queue and work trough the events, 
> also makes it easier to synchronize event processing with rendering 
> and behavioral logic and enables the ecosystem of api users to come up 
> with a solution to correlate events for their favorite devices.

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.


> So I believe that when the gamepad API is moving to this model (and it 
> does by the sound of it) we're good on that front. There's still the 
> question of how to switch "modes" such as mouse emulation or capture 
> to area.

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.


-Charles
Received on Friday, 3 August 2012 16:54:26 GMT

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