[whatwg] Canvas pixel manipulation and performance
Oliver Hunt
oliver at apple.com
Sun Nov 29 20:22:24 PST 2009
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
More information about the whatwg
mailing list