W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2012

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

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 23 Apr 2012 20:00:17 -0700
Message-ID: <4F961741.4080007@jumis.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:07 GMT