[whatwg] createImageData should take unsigned long

[Ian Hickson]

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.


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'