vladimir at pobox.com
Tue May 13 15:32:26 PDT 2008
On May 13, 2008, at 2:58 PM, Oliver Hunt wrote:
> On May 13, 2008, at 1:53 PM, Vladimir Vukicevic wrote:
>> The first argument to the method must be an ImageData object
>> returned by createImageData(), getImageData(), or an object
>> constructed with the necessary properties by the user. If the
>> object was constructed by the user, its width and height dimensions
>> are specified in device pixels (which may not map directly to CSS
>> pixels). If null or any other object is given that does not
>> present the ImageData interface, then the putImageData() method
>> must raise a TYPE_MISMATCH_ERR exception.
> If we were to add that we should include a note to indicate that
> using a custom object is not recommended -- Any code that uses a
> custom created object will never benefit from improvements in
> ImageData performance made by the UA.
I'm fine with adding that language (the first part, anyway); something
like "Using a custom object is not recommended as the UA may be able
to optimize operations using ImageData if they were created via
createImageData() or getImageData()."
> That said I still don't believe custom objects should be allowed,
> aside from the resolution (which may or may not be relevant) and
> performance issues, a custom object with a generic JS array, rather
> than an ImageData object will have different behaviour -- a proper
> ImageData will clamp on assignment, and throw in cases that a custom
> object won't.
That verification seems odd; doing those checks (clamping, conversion
to number) on every single pixel assignment is going the wrong
direction for performance -- you really want to validate everything at
More information about the whatwg