[whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

[Charles Pritchard]

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