W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2013

Re: [whatwg] Polling APIs in JavaScript vs Callbacks

From: Elliott Sprehn <esprehn@gmail.com>
Date: Tue, 12 Feb 2013 15:46:28 -0800
Message-ID: <CAPJYB1ifqP2x4p90yZoCrXCCCbc4Y0V40eke7M3DdEmfGy-urw@mail.gmail.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: Gregg Tavares <gman@google.com>, WHATWG <whatwg@lists.whatwg.org>, Glenn Maynard <glenn@zewt.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith <dhtmlkitchen@gmail.com>wrote:

> On 2/9/13, Glenn Maynard <glenn@zewt.org> wrote:
> > On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr.
> > <jackalmage@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
Received on Tuesday, 12 February 2013 23:47:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:19 UTC