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
