W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] Canvas pixel manipulation and performance

From: Kenneth Russell <kbr@google.com>
Date: Sun, 29 Nov 2009 11:21:27 -0800
Message-ID: <921bb10911291121h47702167yea654f4051c0eef9@mail.gmail.com>
On Sun, Nov 29, 2009 at 11:05 AM, Philip Taylor <excors+whatwg at gmail.com> wrote:
> On Sun, Nov 29, 2009 at 6:59 PM, Kenneth Russell <kbr at google.com> wrote:
>> On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>> 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.
> Would it be helpful (for simplicity or performance or consistency etc)
> to change the specification of CanvasPixelArray to have those "simpler
> clamping semantics"? (I don't expect there would be compatibility
> problems with changing it now, particularly since Firefox doesn't
> implement clamping at all in CPA.)

It would. Vladimir Vukicevic from Mozilla was planning to raise this
issue with the whatwg upon release of the first public draft of the
WebGL spec.

Received on Sunday, 29 November 2009 11:21:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC