- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 23 Apr 2012 20:00:17 -0700
On 4/23/2012 6:50 PM, Glenn Maynard wrote:
> On Mon, Apr 23, 2012 at 12:43 PM, Darin Fisher<darin at 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
Received on Monday, 23 April 2012 20:00:17 UTC