On Mon, Feb 11, 2013 at 10:56 PM, Garrett Smith <[email protected]>wrote:
> On 2/9/13, Glenn Maynard <[email protected]> wrote: > > On Sat, Feb 9, 2013 at 10:43 AM, Tab Atkins Jr. > > <[email protected]>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
