esprehn at gmail.com
Tue Feb 12 15:46:28 PST 2013
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).
More information about the whatwg