[whatwg] Canvas "coordinate space units"

[Aryeh Gregor]

On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan <david at davidflanagan.com> wrote:
> I'm confused by the term "coordinate space units" as applied to the canvas
> spec.  It does not seem to be defined.

It seems clear to me.  The 2D context represents a Cartesian plane,
and the units for everything are units within that plane.  One
coordinate space unit might correspond to any number of pixels,
depending:

"""
The intrinsic dimensions of the canvas element equal the size of the
coordinate space, with the numbers interpreted in CSS pixels. However,
the element can be sized arbitrarily by a style sheet. During
rendering, the image is scaled to fit this layout size.

The size of the coordinate space does not necessarily represent the
size of the actual bitmap that the user agent will use internally or
during rendering. On high-definition displays, for instance, the user
agent may internally use a bitmap with two device pixels per unit in
the coordinate space, so that the rendering remains at high quality
throughout.
"""

> It is used in the definition of the translate() method, for example, and
> seems to imply that coordinate space units are affected by scale()
> operations.

The transformation matrix is referred to in a particular well-defined
way by some methods.  For instance, the rectangle methods say:

"""
The current transformation matrix must be applied to the following
four coordinates, which form the path that must then be closed to get
the specified rectangle: (x, y), (x+w, y), (x+w, y+h), (x, y+h).
"""

This only affects operations where it says so explicitly.  Nothing
that I see says it affects the coordinate space units themselves (if
that even makes sense).

> It is used in the definition of the lineWidth attribute as well. Chrome,
> Firefox and Opera all scaled lineWidth and Phillip Taylor's test suite
> expects this behavior as well.

I can't find where it says lineWidth should be scaled . . .

> But then in the definition of shadowOffsetX and Y, the spec reads:
>
>> Their values are in coordinate space units. They are not affected by the
>> current transformation matrix.
>
> The description of isPointInPath() uses similar language:
>
>>  when treated as coordinates in the canvas coordinate space unaffected by
>> the current transformation,
>
> So which is it?  Are "coordinate space units" affected by scaling or not?

As far as I can tell, no.  When the transformation matrix is used, it
says so explicitly.  The language you point to for shadowOffset and
isPointInPath is just a reminder.  I think.

>  Are lineWidths supposed to be scaled? (Implementations do so consistently)

I don't think they're supposed to be from reading the spec, although I
don't know why not.  Maybe I'm missing something, or maybe this needs
to be clarified.

> Are shadow offset supposed to be scaled? (Chrome does, Firefox and Opera do
> not)

Doesn't it say explicitly that they shouldn't be?

> I think a clearer definition of coordinate spaces would be helpful. Maybe
> "device space" for the underlying pixmap, "canvas space" for the coordinates
> defined by the width and height attributes of the canvas, and "user space"
> for the space defined by the current transformation matrix?

It might be a good idea to separate out the units for stuff affected
by transformations vs. not, yeah.  I don't know why anything shouldn't
be transformed by the current transformation matrix, though.