[whatwg] createImageData should take unsigned long

[Philip Jägenstedt]

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