- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 03 Sep 2009 14:40:49 +0200
On Thu, 03 Sep 2009 13:54:03 +0200, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 31 Aug 2009, Philip J?genstedt wrote: >> On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson <ian at hixie.ch> wrote: >> > On Mon, 24 Aug 2009, Philip J?genstedt wrote: >> > > >> > > As far as I can see there's no good reason why createImageData >> > > should take a float as input rather than unsigned long. Having it as >> > > float creates the odd situation where (0.1, 0.1) gives a 1x1 >> > > ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if >> > > you ceil or round the input (not defined). Unless there's a >> > > compelling reason to allow something like (0.1, 0.1) I suggest >> > > changing the type and leaving the float->unsigned conversion to >> > > WebIDL. >> > >> > Twenty years from now, when we're using 960dpi screens, 1 CSS pixel >> > might well map to ten device pixels reliably, such that people will >> > want sub-CSS-pixel-level accuracy in their calls to createImageData(). >> >> I get the impression this has all been discussed before. Still, it seems >> unlikely that any browser will ever be able to switch to anything but a >> 1:1 CSS pixel:device pixel ratio, as that would break all existing pages >> assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap >> (because assuming that is much easier, unless you read the spec >> carefully you're unlikely to know it could ever be any different). > > Yeah, that seems likely, since none of you implemented the higher-DPI > ImageData in your first versions. :-( > > I expect we'll introduce a new API that actually works once there is a > browser vendor actually interested in supporting higher-DPI canvases. I wasn't involved then, but I can only presume that there was no perceived benefit of high-DPI ImageData since you can get high-quality rendering just as well with techniques that don't rely on the canvas being higher resolution than the display device. >> In any event, judging by existing implementations, the behavior of >> createImageData(w, h) isn't as clear as it needs to be: >> >> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/223 >> >> Firefox: >> >> log: ctx.createImageData(-1.1,1) => [Exception... >> log: ctx.createImageData(-1,1) => [Exception... >> log: ctx.createImageData(-0.1,1) => [Exception... >> log: ctx.createImageData(0,1) => [Exception... >> log: ctx.createImageData(0.1,1) => [Exception... >> log: ctx.createImageData(1,1) => 1x1 >> log: ctx.createImageData(1.1,1) => 1x1 >> >> Safari/Chrome: >> >> log: ctx.createImageData(-1.1,1) => 1x1 >> log: ctx.createImageData(-1,1) => 1x1 >> log: ctx.createImageData(-0.1,1) => 1x1 >> log: ctx.createImageData(0,1) => 1x1 >> log: ctx.createImageData(0.1,1) => 1x1 >> log: ctx.createImageData(1,1) => 1x1 >> log: ctx.createImageData(1.1,1) => 2x1 >> >> My interpretation of the spec: >> >> log: ctx.createImageData(-1.1,1) => 1x1 >> log: ctx.createImageData(-1,1) => 1x1 >> log: ctx.createImageData(-0.1,1) => 1x1 >> log: ctx.createImageData(0,1) => INDEX_SIZE_ERR >> log: ctx.createImageData(0.1,1) => 1x1 >> log: ctx.createImageData(1,1) => 1x1 >> log: ctx.createImageData(1.1,1) => 1x1 > > The spec doesn't say what size the ImageData objects should be in these > cases. Your interpretation is correct insofar as the exception is > concerned, though. > > >> If the spec doesn't say to round rather than ceil, we're bound to have >> subtle compatibility bugs on this. > > The spec says it doesn't matter so long as you're consistent. > > > On Mon, 31 Aug 2009, Robert O'Callahan wrote: >> > >> > Still, it seems unlikely that any browser will ever be able to switch >> > to anything but a 1:1 CSS pixel:device pixel ratio, as that would >> > break all existing pages assuming that getImageData(0, 0, 100, 100) >> > returns a 100x100 bitmap (because assuming that is much easier, unless >> > you read the spec carefully you're unlikely to know it could ever be >> > any different). >> >> I agree, but Ian doesn't. > > It's not so much that I disagree so much as that there is no point fixing > this now, since whatever new API we introduce today will just end up > broken in the exact some way as the existing API. The fix is not to introduce a new API that can handle high-DPI ImageData, but rather to make the spec reflect the reality that high-DPI ImageData implementations won't be possible with this version of the API. That would include, among other things, specifying that getImageData(0, 0, w, h) returns a wxh ImageData object, removing createImageData(ImageData) and making createImageData(w, h) take unsigned long and return a wxh ImageData object. In other words, aligning with what implementations already do (and will continue to do for compatibility reasons). -- Philip J?genstedt Core Developer Opera Software
Received on Thursday, 3 September 2009 05:40:49 UTC