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

[Mike Shaver]

On Mon, Mar 15, 2010 at 3:05 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> === 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.

With hardware acceleration in play, things seem to change a lot there,
though it may be that it's just breaking the test somehow?  The
displayed images look correct, FWIW.

My results on a Windows 7 machine, with the browsers maximized on a
1600x1200 display.

FF 3.6:
direct copy: 8ms
indirect: 408ms
2x scale: 1344ms
0.5x scale: 85ms
rotate: 440ms

FF 3.7a (no D2D):
direct copy: 12.5ms
indirect: 101ms
2x scale: 532ms
0.5x scale: 33ms
rotate: 389ms

FF 3.7a (D2D):
direct copy: 0.5ms
indirect: 136ms
2x scale: 0.5ms
0.5x scale: 0.5ms
rotate: 0.5ms

WebKit r56194:
direct copy: 18.5ms
indirect copy: 113ms
2x scale: 670ms
0.5x scale: 112ms
rotate: 129ms

This supports the idea of specialized API, perhaps, since it will keep
authors from having to figure out which path to take in order to avoid
a massive hit  when using the canvas copies (100x or more for
D2D-enabled FF, if the test's results are correct).  It also probably
indicates that everyone is going to get a lot faster in the next
while, so performance tradeoffs should perhaps not be baked too deeply
into the premises for these APIs.

Other more complex tests like blurring or desaturating or doing edge
detection, etc. may show other tradeoffs, and I think we're working on
a performance suite for tracking our own work that may illuminate some
of those.  Subject, of course, to the incredibly fluid nature of all
browser performance analysis these days!

Mike