- From: Vladimir Vukicevic <vladimir@pobox.com>
- Date: Tue, 13 May 2008 15:32:26 -0700
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
Received on Tuesday, 13 May 2008 15:32:26 UTC