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

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

We're clearly going in circles here. My point is this:

The two main use cases that has brought up have been scaling and
rotating images off the main thread in order to improve
responsiveness. The proposed solution addresses these use cases fairly
poorly. Both in that APIs could be designed that makes these things
simpler, and in that APIs could be designed that perform better both
by putting less work on the main thread, and by doing less work in
general.

This does not take away from the fact that the proposal can be (based
on your data) be used to improve performance when doing scaling.

/ Jonas

Received on Monday, 15 March 2010 00:28:41 UTC