- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 03 Aug 2012 09:54:03 -0700
- To: Florian Bösch <pyalot@gmail.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <501C022B.6060200@jumis.com>
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 UTC