- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 14 May 2007 10:02:51 +0200
On Mon, 14 May 2007 03:01:50 +0200, Maciej Stachowiak <mjs at apple.com> 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/>
Received on Monday, 14 May 2007 01:02:51 UTC