[whatwg] Offscreen canvas (or canvas for web workers).
mjs at apple.com
Mon Mar 15 00:05:11 PDT 2010
On Mar 14, 2010, at 6:22 PM, Jonas Sicking wrote:
> One way to do it would be to have an function somewhere, not
> necessarily on the 2D context, which given a Blob, returns an
> ImageData object. However this still results in the image being loaded
> twice into memory, so would only really help if you want to operate on
> an ImageData object directly.
I think loading via an <img> element in order to draw the image is
fine. An HTMLImageElement is just as drawable as an ImageData and
already has all the logic for asynchronous loading of images and
> I agree that the number of steps is not important for responsiveness
> or performance (though it is for complexity). However several of those
> steps seemed to involved non-trivial amount of CPU usage, that was the
> concern expressed in my initial mail.
> At the very least I think we have a skewed proposal. The main use
> cases that has been brought up are scaling and rotating images.
> However the proposal is far from optimal for fulfilling that use case.
> For scaling, it's fairly complex and uses more CPU cycles, both on the
> main thread, and in total, than would be needed with an API more
> optimized for that use case. For rotating it doesn't do anything.
You're assuming a scale and a rotate are both less expensive than two
blits. Since no one else has provided perf data, I made my own test:
=== Results ===
= Safari (w/ WebKit trunk) =
Direct image copy: 39ms
Indirect copy with (via ImageData): 138.5ms
Copy with 2x scale: 717ms
Copy with 0.5x scale: 59.5ms
Copy with rotate:142.5ms
= Chrome dev 5.0.322.2 =
Direct image copy: 63ms
Indirect copy with (via ImageData): 161.5ms
Copy with 2x scale: 1376.5ms
Copy with 0.5x scale: 70.5ms
Copy with rotate: 259ms
= Opera 10.5 alpha =
Direct image copy: 89ms
Indirect copy with (via ImageData): 428.5ms
Copy with 2x scale: 963.5ms
Copy with 0.5x scale: 61ms
Copy with rotate: 150ms
= Firefox 3.6 =
Direct image copy: 81ms
Indirect copy with (via ImageData): 693.5ms
Copy with 2x scale: 1703.5ms
Copy with 0.5x scale: 284.5ms
Copy with rotate: 568.5ms
=== Summary of Data ===
1) In all browsers tested, copying to an ImageData and then back to a
canvas (two blits) is faster than a 2x scale.
2) In all browsers tested, twice the cost of a canvas-to-canvas blit
is considerably less than the cost of copy to and back from ImageData.
3) In all browsers tested, twice the cost of a canvas-to-canas blit is
still less than the cost of a single 0.5x scale or a rotate.
=== Conclusions ===
1) For scaling an image up 2x, copying to an ImageData and back for
processing on a Worker would improve responsiveness, relative to just
doing the scale on the main thread.
2) 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.
More information about the whatwg