[whatwg] Offscreen canvas (or canvas for web workers).

On 3/15/2010 4:22 AM, Maciej Stachowiak wrote:
>
> On Mar 15, 2010, at 3:46 AM, Philip Taylor wrote:
>
>> On Mon, Mar 15, 2010 at 7:05 AM, Maciej Stachowiak <mjs at apple.com> 
>> wrote:
>>> Copying from one canvas to another is much faster than copying to/from
>>> ImageData. To make copying to a Worker worthwhile as a responsiveness
>>> improvement for rotations or downscales, in addition to the 
>>> OffscreenCanvas
>>> proposal we would need a faster way to copy image data to a Worker. One
>>> possibility is to allow an OffscreenCanvas to be copied to and from a
>>> background thread. It seems this would be much much faster than 
>>> copying via
>>> ImageData.
>>
>> Maybe this indicates that implementations of getImageData/putImageData
>> ought to be optimised? e.g. do the expensive multiplications and
>> divisions in the premultiplication code with SIMD. (A seemingly
>> similar thing at http://bugzilla.openedhand.com/show_bug.cgi?id=1939
>> suggests SSE2 makes things 3x as fast). That would avoid the need to
>> invent new API, and would also benefit anyone who wants to use
>> ImageData for other purposes.
>
> It might be possible to make getImageData/putImageData faster than 
> they are currently, certainly the browsers at the slower end of the 
> ImageData performance spectrum must have a lot of headroom. But they 
> probably also probably have room to optimize drawImage. (Looking back 
> at my data I noticed that getImageData + putImageData in Safari is 
> about as fast or faster than two drawImage calls in the other browsers 
> tested).
>
> In the end, though, I doubt that it's possible for getImageData or 
> putImageData to be as fast as drawImage, since drawImage doesn't have 
> to do any conversion of the pixel format.

This is true -- getImageData/putImageData unfortunately saddled us with 
two performance-killing bits:

1) clamping on assignment.  Not so bad, but doesn't help.

2) Unpremultiplied alpha.  This is the biggest chunk.  We have more 
optimized code in nightly builds of Firefox now that uses a lookup table 
and gets a pretty significant speedup for this part of put/get, but it's 
not going to be as fast as drawImage.

Also, canvas is often (or can be) backed by actual hardware surfaces, 
and drawImage from one to another is going to be much faster than 
reading the data into system memory and then drawing from there back to 
the hardware surface.

If we wanted to support this across workers (and I think it would be 
helpful to figure out how to do so), something like saying that if a 
canvas object was passed (somehow) between workers, it would be a copy 
-- and internally it could be implemented using copy-on-write semantics.

     - Vlad

Received on Monday, 15 March 2010 14:24:11 UTC