On Mon, 14 May 2007 03:01:50 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
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.
Just to keep this list in sync with #whatwg. It was suggested to give both
putImageData and getImageData a "high resolution" boolean parameter which
would indicate what type of ImageData object you would get back. This
would be fine by me. I'm not sure if that's needed right away though.
(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.
Agreed.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
