[whatwg] Offscreen canvas (or canvas for web workers).
mike.shaver at gmail.com
Mon Mar 22 07:34:01 PDT 2010
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
direct copy: 8ms
2x scale: 1344ms
0.5x scale: 85ms
FF 3.7a (no D2D):
direct copy: 12.5ms
2x scale: 532ms
0.5x scale: 33ms
FF 3.7a (D2D):
direct copy: 0.5ms
2x scale: 0.5ms
0.5x scale: 0.5ms
direct copy: 18.5ms
indirect copy: 113ms
2x scale: 670ms
0.5x scale: 112ms
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!
More information about the whatwg