[whatwg] Canvas pixel manipulation and performance

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
values.

-Ken

> 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
>
>

Received on Monday, 30 November 2009 08:46:41 UTC