- From: Elliott Sprehn <esprehn@gmail.com>
- Date: Tue, 12 Feb 2013 15:46:28 -0800
- 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