[whatwg] custom ImageData objects

[Maciej Stachowiak]

On May 13, 2007, at 2:49 AM, Anne van Kesteren wrote:

> In a reply to a message from Mathieu Hixie indicated that you can  
> create your own ImageData objects easily in ECMAScript:
>
>   var data = { height:1, width:1, data:[0,0,0,0] }
>   context.putImageData(data, 0, 0)
>
> I would like the specification to clarify how exactly these custom  
> ImageData objects are to be created and what an implementation hsa  
> to do with them. Several questions about these custom objects:
>
>  * What if it has missing members.
>  * What if it has additional members.
>  * What if the values of the members are incorrect.
>    - height contains a function
>    - data is a two-digit array
>    - etc.
>  * What if the combination of values of the members is
>    incorrect.
>    - height and width say 2, but data only contains a
>      four-digit array.
>
> If this is indeed to be allowed (and it seems to work fine in  
> Firefox) this is an additional argument for not having a  
> distinction between the <canvas> "back end" grid and the actual  
> <canvas> grid as people will just assume they map one to one once  
> it works that way in an implementation they test in.

If we disallow scaling the backing store for a possible UI scale  
factor, then <canvas> content will look significantly worse than  
equivalent SVG content at the same resolution. <canvas> already has  
the problem of worse printed output, as screens become higher and  
higher DPI the same problem will start happening on-screen. It will  
also lead to wasted memory if your UI is scaled down.

I think the only things that expose this scale factor are ImageData  
and toDataURL(). It would be a shame to limit the output quality of  
<canvas> on high DPI screens solely for these two features.

toDataURL() could be defined not to, or could hypothetically allow  
image formats that can support multi-scale resolutions such as TIFF  
(in which case drawing it back to the same canvas will do the right  
thing with no loss of quality). We could also come up with a PNG  
extension for multi-resolution images.

I'm not sure of the right fix for ImageData. One possibility is that  
ImageData is in <canvas> coordinates and the pixel values are  
averaged if the backing store is scaled, but then putImageData 
(getImageData(...)) could not be idempotent. Another possibility is  
to have ImageData contain representations at both <canvas> resolution  
and true backing store resolution, so authors have the possibility of  
ignoring scale factor or not. But then you couldn't just use an  
arbitrary JS object as an ImageData, since the two representations  
would have to be kept in sync.

> (Given that you can create them yourself I'm not sure why ImageData  
> has readonly attributes, but maybe that would save some additional  
> checking...)

Ironically, due to the readonly attributes you couldn't just use a  
vanilla JS object as the implementation, even though you have to  
accept is as a value.

Also, if it's meant to be required for implementations to allow that,  
the spec should say so - it's not normally assumed that any JS object  
with the right properties can be used anywhere that an interface can  
be used.

Regards,
Maciej