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

[whatwg] Canvas pixel manipulation and performance

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 29 Nov 2009 00:09:48 -0500
Message-ID: <4B12021C.6010809@mit.edu>
On 11/28/09 3:44 PM, Jason Oster wrote:
> The trouble with profiling my project is that it is a XULRunner
> application, and does not run directly in web browsers as-is.

This is not an issue at all; any XULRunner application can be run in 
Firefox directly (with the right command-line flags).  I'm happy to 
profile whatever set of operations you want for you in Firefox if you 
send me step-by-step instructions for performing that set of operations 
in your application, ideally with code pointers to the start and stop of 
the code to be profiled in your codebase.  Probably offlist for all 
that... ;)

Of course if you have a Mac you can do all this yourself; Shark is an 
excellent tool.

> Changeset 2b56c4771d5c reduced the number of pixel array elements
> accessed by caching the 256px x 256px "rooms" within the stage map, and
> passing the cached rooms to putImageData().

As opposed to doing what before the change?

> My point, as you concur, is that setting four array elements
> (properties) is slower than setting just one.

While true, it may not necessarily be slower than setting one if the 
value to set is more expensive to compute as a result, and may not be 
the bottleneck to start with.  The latter is hard to determine without 
profiling.  My gut feel is that at least in Gecko this is not likely to 
be a performance bottleneck right now, nor much of a win with the 
proposed change, if any.  But again, that would be easier to judge (at 
least for the first part) with a profile.

-Boris
Received on Saturday, 28 November 2009 21:09:48 UTC

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