- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 20 Apr 2012 08:53:02 -0500
On Thu, Apr 19, 2012 at 11:28 PM, Maciej Stachowiak <mjs at apple.com> wrote: > You could also address this by adding a way to be notified when the > contents of an ImageData are available without blocking. That would work > with both vanilla getImageData and the proposed getImageDataHD. It would > also give the author the alternative of just blocking (e.g. if they know > the buffer is small) or of sending the data off to a worker for processing. > This would result in people writing poor code, based on incorrect assumptions. It doesn't matter how big the buffer is; all that matters is how long the drawing calls before the getImageData take. For example, if multiple canvases are being drawn to (eg. on other pages running in the same thread), they may share a single drawing queue. Any time you retrieve image data synchronously, and it happens to require a draw flush, you freeze the UI for all pages sharing that thread. Why is that okay for people to do? We should know better by now than to expose APIs that encourage people to block the UI thread, after spending so much time trying to fix that mistake in early APIs. (This should expose a synchronous API in workers if and when Canvas makes it there, of course, just like all other APIs.) -- Glenn Maynard
Received on Friday, 20 April 2012 06:53:02 UTC