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 <m...@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
