[whatwg] createImageData

[Oliver Hunt]

>
>> 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).

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.

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.

>
>   - Vlad
>

--Oliver