W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2008

[whatwg] createImageData

From: Vladimir Vukicevic <vladimir@pobox.com>
Date: Tue, 13 May 2008 15:50:02 -0700
Message-ID: <3176995D-372E-4430-A2F6-0605E93123E8@pobox.com>

On May 13, 2008, at 3:37 PM, Oliver Hunt wrote:
>>> 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.
> But by delaying clamping, etc you are requiring that the backing  
> store be an array of boxed values, leading to increased memory  
> usage, increased indirection, and increasing the cost of the final  
> blit.

That's an implementation detail, I guess..

> My experience implementing this in WebKit showed a pure byte array  
> backing store was significantly faster than using boxed values.

Faster for which operation, though?  The put, or the actual  
manipulation?  It's a tradeoff, really; if you're doing limited pixel  
manipulation, but lots of putImageData, you can optimize that directly  
by just calling putImageData once to an offscreen canvas and then  
blitting that with drawImage.  If you're doing lots of pixel  
manipulation but only one putImageData, I guess you can use a JS array  
for your intermediate ops to avoid the checking overhead, and set the  
image data pixels all at once (though again paying the checking  
penalty per pixel), but having cheap putImageData.

Throwing the error at putImageData time lets the implementation  
optimize in whatever way is most convenient/performant (either at  
pixel operation time by setting an error bit in the ImageData object  
which is checked by putImageData, or at putImageData time), and is  
(IMO) more flexible.. given that errors are an exceptional case, I  
don't think the spec should force the checking per pixel.

    - Vlad
Received on Tuesday, 13 May 2008 15:50:02 UTC

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