[whatwg] createImageData

[Vladimir Vukicevic]

On May 13, 2008, at 4:10 PM, Oliver Hunt wrote:
>>
>>> 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.
>
> I found it faster in general across quite a few tests.  I would  
> argue that if you are using ImageData in a way that leads to you  
> writing to the same pixel multiple times you should improve your  
> algorithms (this is just the generic over painting issue).

I dunno, some kind of iterative algorithm that you want to visualize  
at random timesteps.  You could keep the output in a separate array  
and copy over when you want to render it.

> A very reall issue to consider though is the case where I've been  
> very careful to only update those pixels that need to be updated.   
> If the ImageData is not clamped, etc on put then *every* blit must  
> do a complete revalidation of the entire ImageData data buffer.

Yep, that's true.

> I think we need a list of use cases for ImageData, off the top of my  
> head i can think of:
> * filters -- in general a single write per pixel, potentially  
> multiple reads
> * Generated images -- still arguably single write per pixel
> * I'm not sure what to call this -- but things like http://jsmsxdemo.googlepages.com/jsmsx.html
>
> I honestly can't think of something that would (sanely) expect to be  
> writing multiple times to the same pixel between blits, but i should  
> note i haven't actively spent any significant time trying to come up  
> with these.  That said in all of the above cases the cost of  
> immediate clamping is technically the same as delaying the clamp,  
> although it also has the benefit of allowing reduced memory usage.

Yeah, those are all good use cases -- it just seems like requiring  
immediate clamping is basically specifying for a specific  
implementation, when the overall goal is "checking for invalid data".   
Specifying that the error should come from putImageData would give  
implementations more flexibility, without limiting error checking.   
(You could argue that it's easier to get a precise error location by  
checking on pixel assignment, but I don't think that the potential  
cost and loss of flexibility is worth it.  Once authors know that they  
have an error in their data, they can take other action to track it  
down.)

     - Vlad