On Apr 22, 2012, at 7:10 PM, Glenn Maynard wrote: > On Sun, Apr 22, 2012 at 8:03 PM, Maciej Stachowiak <m...@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
