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

[whatwg] createImageData

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 13 May 2008 16:49:01 -0700
Message-ID: <B27A91CD-A9A8-4BA8-8A3B-F1802F5A1314@apple.com>

On May 13, 2008, at 4:28 PM, Vladimir Vukicevic wrote:

>
> On May 13, 2008, at 4:10 PM, Oliver Hunt wrote:
>
>> 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.

Wouldn't delaying clamping and error checking make it hard to use a  
native pixel data array as the ImageData backing store? In fact it  
would make it pretty much impossible unless you at least clamp/round/ 
throw when reading the data from JS. And even then, such an ImageData  
implementation would have to taint itself to record whether an error  
had occurred.

Regards,
Maciej
Received on Tuesday, 13 May 2008 16:49:01 UTC

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