On 4/23/2012 6:50 PM, Glenn Maynard wrote:
On Mon, Apr 23, 2012 at 12:43 PM, Darin Fisher<da...@chromium.org> wrote:
That said, I've come around to being OK with getImageDataHD. As I wrote
recently, this is because it is possible to implement that in a
non-blocking fashion. It can just queue up a readback. It only becomes
necessary to block the calling thread when a pixel is dereferenced. This
affords developers with an opportunity to instead pass the ImageData off to
a web worker before dereferencing. Hence, the main thread should not jank
up. This of course requires developers to be very smart about what they
are doing, and for browsers to be smart too.
It's reasonable to expect users to use async APIs in the main thread;
that's just a part of the platform. It's not reasonable to expect people
to fire up a worker and transfer the buffer to the worker to prevent the
blocking from happening in the main thread. That's a particularly hackish
workaround, not a replacement for an async API.
Looks like Maciej wants this one in ASAP as a synchronous method.
Dev's are still going to jank up their main thread when working with
getImageDataHD.
As a couple here have stated -- there's a lot more data with an HD layer.
Processing filters on the main thread has always been a UI blocker.
Here's a +1 to allowing
worker.postMessage(document.getCSSCanvasContext('2d','layer','1','1'))
in web workers.
It's completely non-standard but lets us all off the hook.
-Charles
