[whatwg] Polling APIs in JavaScript vs Callbacks

[Elliott Sprehn]

On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:

> On 2/9/13, Glenn Maynard <glenn at zewt.org> wrote:
> > 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.
> Are you proposing event quantization threshold?
>

There's no reason to have a threshold. We should just batch and deliver at
checkpoints like end-of-microtask (MutationObserver) or rAf (Animations).

- E