[whatwg] Canvas pixel manipulation and performance

[Oliver Hunt]

On Nov 29, 2009, at 10:59 AM, Kenneth Russell wrote:

> On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> On 11/29/09 12:15 AM, Kenneth Russell wrote:
>>>> 
>>>> I assume you meant JS bitwise operators?  Do we have any indication that
>>>> this would be faster than four array property sets?  The bitwise ops in
>>>> JS
>>>> are not necessarily particulary fast.
>>> 
>>> Yes, that's what I meant. I don't have any data on whether this would
>>> currently be faster than the four separate byte stores.
>> 
>> Are they even byte stores, necessarily?  I know in Gecko imagedata is just a
>> JS array at the moment; it stores each of R,G,B,A as a JS Number (with the
>> usual "if it's an integer store as an integer" optimization arrays do).
>>  That might well change in the future, and I hope it does, but that's the
>> current code.
>> 
>> I can't speak to what the behavior is in Webkit, and in particular whether
>> it's even the same when using V8 vs Nitro.
> 
> In Chromium (WebKit + V8), CanvasPixelArray property stores write
> individual bytes to memory. WebGLByteArray and WebGLUnsignedByteArray
> behave similarly but have simpler clamping semantics.

I don't know where you're getting that idea from -- the clamping semantics for CanvasPixelArray and WebGLUnsignedByteArray are identical.

The CanvasPixelArray implementation in WebKit has always matched the spec and been a clamping bytearray, eg. one byte per channel, per pixel.

Just for future reference for all who are interested: in WebKit the JS interface to a DOM object is merely a binding to a C++ implementation, eg. there's no reason to be concerned about different DOM object behaviour dependent on the JS engine - if there were it a difference would imply a bug rather than a design choice.

--Oliver

> 
> -Ken