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

[Maciej Stachowiak]

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  
processing

> 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:

http://webkit.org/demos/canvas-perf/canvas.html

=== 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.


Regards,
Maciej