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

[whatwg] fxCanvas 0.2 and some remarks about canvas spec

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 13 Nov 2010 23:20:30 -0500
Message-ID: <4CDF638E.8070600@mit.edu>
On 11/13/10 12:20 PM, Evgeny Burzak wrote:
> But , the test results looks  similar for all vendors! On average the
> difference in processing speed is about 2-3 times (five times in
> Firefox 4).

 > This is due to the fact that loops take less time (width x
> height * 4 vs. width x height) and arrays with less elements take less
> memory.  Though I realize that main idea for data structure was
> simplicity, but in this case it seems simplicity is evil, not good.

At least Gecko and Webkit implement canvas imagedata as something more 
like a WebGL typed array, not a JS array.  So in particular, the memory 
usage is the same or better as for your "compact" array version (in the 
case of Gecko actually 2x better, since your "compact" array uses 8 
bytes per color, while the native imagedata uses 4 bytes per color). 
Yes that gives a significant speedup due to less memory traffic and 
better cache locality.

But this is only a problem for emulating canvas, no?  And only in UAs 
that don't support typed arrays, say.  That all seems like a transitory 
problem.

For what it's worth, I just tried modifying your testcase to include a 
test of Uint8ClampedArray, which is what Gecko uses for canvas imagedata 
under the hood; the test looks just like your "canvas data" test except 
for the different array type in the new() call.  That test ends up about 
20% faster than your "packed" test...

-Boris
Received on Saturday, 13 November 2010 20:20:30 UTC

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