[whatwg] Canvas pixel manipulation and performance

[Ian Hickson]

On Thu, 26 Nov 2009, Jason Oster wrote:
> 
> I've been using canvas to draw pixel art (NES/SNES game screens and 
> sprites) similar to what an emulator would do.  Doing this kind of 
> drawing requires direct access to the pixel buffer.
> 
> My problem with the canvas spec (as it is now) is that it tends to 
> artificially bounds pixel drawing performance to JavaScript when doing 
> any sort of pixel access.  Setting four unsigned 8-bit array elements 
> (R, G, B, and A) is a slower operation that setting just one unsigned 
> 32-bit array element (RGBA or ABGR).  Sadly, we don't have this latter 
> option for canvas.
>
> My comment is a request for a new set of pixel access methods on the 
> CanvasRenderingContext2D object.  Specifically, alternatives to 
> createImageData(), getImageData(), and putImageData() methods for 
> providing an array of unsigned 32-bit elements for pixel manipulation.

This comes up every now and then, but in the big picture, this problem 
isn't a huge issue. I think it's better that we wait for the rest of the 
spec to be better implemented before we start adding more features to 
<canvas>. Even in <canvas>, there are a number of features that would 
probably be more important than this, such as reusable path objects, text 
on a path, or dotted or dashed line styles.

If we had data showing that it was a problem, that might change matters.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'