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
once.
- Vlad
