[whatwg] Polling APIs in JavaScript vs Callbacks

[Glenn Maynard]

On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> That said, there *are* still some isolated use-cases for polling.  ^_^
>  When an event-based approach would potentially deliver far too many
> events, with separation between them perhaps less than 1ms, exposing a
> polling-based API instead can be useful.  I haven't followed the
> Gamepad API lately, but I know this was at least considered for some
> of the types of feedback, such as the exact position of joysticks or
> pressure on buttons, both of which can change very rapidly in
> realistic scenarios.
>

A polling API doesn't help you there, since you can't poll every 1ms in
script (certainly not in the UI thread, and probably not reliably even in a
worker).  In fact, since setTimeout will be throttled but events fired by
the browser don't have to be, events can be sent faster than you can poll
in the UI thread (though this is probably a bad idea most of the time).

The solution is probably a matter of buffering the changes, and limiting
how frequently "something was buffered" events fire.  That way, you can get
low-latency, high-time-resolution data if you want it, by reading all a
list of changes made since the last event, without trying to poll at 1kHz
in script.  (I have a vague recollection of proposing exactly this, but I
don't think it went anywhere and I haven't seen any discussion about the
gamepad API here or on -webapps in a long time.)

-- 
Glenn Maynard