[whatwg] proposed canvas 2d API additions

[Vladimir Vukicevic]

On 5/9/06, Anne van Kesteren <fora at annevankesteren.nl> wrote:
> Quoting Vladimir Vukicevic <vladimirv at gmail.com>:
> >> I agree that they shouldn't be affected by the CTM, but I disagree that
> >> they should be integers. e.g. in cases like:
> >>
> >>   HTML                          CSS
> >>   <canvas height=1 width=1>     canvas { height: 100%; width: 100%; }
> >>   </canvas>
> >>
> >> ...where the JS then uses the coordinate space 0..1,0..1 the author might
> >> want to grab the top corner by grabbing the 0,0,0.25,0.25 rect.
> >
> > So, I really don't like this -- we need to nail down space the
> > getPixels/setPixels coordinates should be in.  I still think that they
> > should always be in the canvas space, no matter how many pixels they
> > refer to in the rendered content or in the device space.  Note that in
> > your example, the canvas can still be a 1x1 pixel canvas (and, I
> > believe, will be in all current implementations) -- that one pixel
> > will just cover the entire page.
>
> That is what Ian is saying. He's saying it's a 1x1 pixel canvas just
> that within that 1x1 pixel there could be different subpixels with
> different colors you could try to get using floating points instead of
> integers.

Ah, I see.  That sounds fine, then, but I think that the spec then has
to explicitly state that non-integer coordinates cannot guarantee a
getPixels/setPixels round-trip.  This is because the user might end up
specifying a fractional device-space pixel, and no matter what
approximation ends up being used it may result in an unexpected change
on that border pixel.  (Think of a 2x2 canvas with a 4x4 backing
store, and the user requesting 0,0,0.25,0.25.)  Alternatively, the
spec might say that a round-trip is only guaranteed if the entire
canvas dimensions are passed to getPixel/setPixel, to account for the
case of, say, 2.5 backend pixels being used to represent 1 canvas
unit.

   - Vlad