[whatwg] Canvas pixel manipulation and performance

Kenneth Russell kbr at google.com
Mon Nov 30 08:46:41 PST 2009

On Sun, Nov 29, 2009 at 8:22 PM, Oliver Hunt <oliver at apple.com> wrote:
> 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.

CanvasPixelArray specifies that values greater than 255, including
+inf, are clamped to 255 and values less than 0, including -inf, are
clamped to zero. WebGLUnsignedByteArray (as people will see in the
WebGL draft spec this week or next) specifies that the conversion is
done with a C-style cast. The results are different for out-of-range


> 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

More information about the whatwg mailing list