[webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

Charles Pritchard chuck at jumis.com
Mon Apr 16 13:07:19 PDT 2012

On 4/16/2012 12:55 PM, Maciej Stachowiak wrote:
> On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
>> Could this be an opportunity to design an asynchronous API for 
>> fetching the pixel buffer?  It seems like many implementations are 
>> GPU backed now, and fetching the pixel buffer is an expensive 
>> (blocking) operation.  Had you considered making such a change?
> Adding async support was suggested on the whatwg thread about this. I 
> think async support is useful, but should not be tied to high DPI 
> support. In particular, we shouldn't, in my opinion, require authors 
> to rewrite their existing sync code to an async model just to properly 
> support higher resolutions.

TL;DR: Canvas authors will largely be using web workers (thus async) 
regardless of this proposal.

Oliver Hunt is suggests that an async fetch would be of "significant 
additional complexity for content authors"; Maciej, you're also saying 
that "authors [would have] to rewrite their existing sync code".

ImageData operations are very much a niche, a very small niche, inside 
of yet another very small niche. Canvas is an expensive low-level API to 
work with. Cheaper than SVG support, but still expensive.
Authors working with Canvas have taken on complexity already.

All authors working with Canvas ImageData are looking at it from an 
async perspective because they'd like to offload the work to another thread.
We've had to wait awhile for it but webkitPostMessage and 
Uint8ClampedArray are coming along. Those are already an async pairing.

Further, we can do little optimizations to treat the typed array as a 
Float32. Once we're knee-deep in ImageData, everything is on the table.

The "code complexity" of async vs sync on ImageData is minor. Authors 
are looking at using async anyway so that they have the option to move 
the heavy lifting off-thread so as not to block the UI.

I just have to disagree with Oliver and Maciej here on the "complexity" 
and "rewrite" portions. 1) It's already being done as common practice so 
as not to block the UI, 2) It's not complex nor a rewrite, it's just a 
simple layer
of code, and 3) we're already looking at far more complex things in 
Canvas such as simply supporting requestAnimationFrame.


More information about the webkit-dev mailing list