On Thu, 03 Sep 2009 13:54:03 +0200, Ian Hickson <[email protected]> wrote:
On Mon, 31 Aug 2009, Philip J�genstedt wrote:
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson <[email protected]> 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
