- From: Glenn Maynard <glenn@zewt.org>
- Date: Sun, 22 Apr 2012 21:10:18 -0500
On Sun, Apr 22, 2012 at 8:03 PM, Maciej Stachowiak <mjs at apple.com> wrote: > All JavaScript that runs on the main thread has the potential to "freeze > the UI for all pages sharing that thread". > APIs on the main thread are designed to allow developers to avoid doing just that. If the *only* way to do something has that potential, then it's a bug in the API. Some feel that a call that reads from the GPU may also be in this category > of "intrinsically too slow/unpredictable". However, we are talking about > operations with a much lower upper bound on their execution time. > If the reasonable upper bound is high enough to cause visible UI degradation, and an asynchronous API can prevent that, then it needs an asynchronous API. If adding an async version has not been an emergency so far, then I don't > think it is critical enough to block adding scaled backing store support. > I hope we doesn't need an emergency to fix problems. Nobody's proposing blocking anything, just providing a better API. This doesn't impose any requirements on implementations who don't need it; it just makes it possible for those who do. Those who don't can always block and queue the callback to happen as soon as the script returns to the event loop--doing it better is just QoI. -- Glenn Maynard
Received on Sunday, 22 April 2012 19:10:18 UTC