- From: Vladimir Vukicevic <vladimirv@gmail.com>
- Date: Fri, 12 May 2006 08:37:51 -0700
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
Received on Friday, 12 May 2006 08:37:51 UTC