W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2010

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 15 Mar 2010 00:05:11 -0700
Message-ID: <3AB67DD2-8917-445A-A8E9-8BB8C2A9ACFC@apple.com>

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.

Received on Monday, 15 March 2010 00:05:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC