- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 23 Apr 2012 01:07:47 -0700
On Apr 22, 2012, at 7:10 PM, Glenn Maynard wrote: > 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. For the record, I don't object to adding an async version of getImageData, or some alternate means of getting async behavior. I would, however, object to: - Removing the existing synchronous getImageData (too much compatibility impact at this point) - Forcing getImageDataHD to only offer an async variant, despite synchronous getImageData existing probably indefinitely At least the latter has been advocated previously on this thread. It's not clear to me what you are personally advocating, so I cannot tell if I disagree with you. Regards, Maciej
Received on Monday, 23 April 2012 01:07:47 UTC