[whatwg] Canvas path objects and path transformations

[Ian Hickson]

On Sun, 15 Apr 2007, Jordan OSETE wrote:
>
> Currently, there are only ways to _set_ the last point of a subpath 
> (through any of the xxxxTo() commands), but not to read it. Since it 
> must be kept in the UA's memory anyway, why not have a getLastPoint() 
> function? If not, it forces the user to keep himself track of the last 
> point (or (s)he needs to override all of the xxxxTo functions to do that 
> "transparently").
>
> Less important, but probably easy to implement as well: relative xxxxTo 
> commands. I mean relative to the last point. Maybe new functions like 
> moveToRel/lineToRel/etc., or a context property "pathBase" to set the 
> base for path API moves ("absolute" and "relative"). The latter would 
> avoid creating thousands of functions (especially if another kind of 
> coordinates must be added in the future).

On Sun, 15 Apr 2007, Maciej Stachowiak wrote:
> 
> If we wanted to have more introspection of paths, I think it would make 
> sense to have a path object and let you get one for the current path.

On Mon, 16 Apr 2007, Jordan OSETE wrote:
> 
> Indeed, it would be the best way, though retrieving the last point would 
> still be handy, and probably simpler to implement ;)
>
> If this is accepted, a "getLastAngle" would be useful as well, wich 
> would return the angle of the tangeant to the last path component drawn, 
> at the last point. The browser already knows how to calculate that (it 
> has to know because of line joins and miter limit).

I haven't added any of these (relative moves and path introspection) in 
this version of the API. I'm not sure they're actually really needed. You 
could relatively easily put a layer to do it on top of the API if you 
wanted. This would fall into the same category as making a layer that uses 
polar coordinates.



On Sun, 15 Apr 2007, Maciej Stachowiak wrote:
> 
> You can achieve relative moves by doing a translation to the current 
> point when drawing; this is a more general version of what your pathBase 
> property would do.

On Sun, 15 Apr 2007, Stefan Haustein wrote:
>
> the WHATWG spec says you cannot do so (section 3.14.11.1.8):
> 
> "Note: The transformation is applied to the path when it is drawn, not 
> when the path is constructed. Thus, a single path can be constructed and 
> then drawn according to different transformations without recreating the 
> path."
> 
> BTW: The Mozilla Developer Connection clock sample relies on applying 
> transformations at construction time, but runs fine in Firefox 2, so at 
> least the Firefox implementation seems to be non-conforming in this 
> respect.
> 
> In my opinion, relative moves easily become confusing in the case of 
> Bezier Curves (what is the point of reference for the third and fourth 
> coordinate pair?), and additional methods would basically be redundant 
> without significant gains in functionality or speed.

[...]

> Yes, but there are complex shapes that can be made really easier to draw 
> this way. On the other hand, the way the current specification works 
> allows to construct a single shape once, and draw it in different ways 
> around, by just modifying the transform attribute...
>
> It would be nice to have both, being able to use transformations 
> independantly for drawing and constructing the path.
>
> I don't know if it would be very hard to implement or not? (well, 
> obviously not for the mozilla project, since they already have it ;)

[...]

On Mon, 16 Apr 2007, Jordan OSETE wrote:
> 
> Hm, i think i can agree. As mentionned before, transformations would be 
> more versatile for this purpose, and the whole 3*3 matrix is used 
> everywhere, so it is well known. If we can have a mecanism affecting the 
> path when it is constructed, transformations would probably be better.

Based on the above, I've left the spec as is for now (it's what Opera 
implements); but I've contact the browser vendors about this and I'm 
looking into it as we speak. Check the spec for updates to this issue.


On Mon, 16 Apr 2007, Stefan Haustein wrote:
> 
> in my opinion, preserving the path for re-use does not buy much: Path 
> construction at this level is just appending a few coordinates and 
> meta-information to an array. Since there is no knowledge about future 
> transformations, one needs to keep the original coordinates instead of 
> the device coordinates, and it is not possible to calculate segment 
> count for Bezier curves etc.
> 
> Moreover, if the path is not re-used, keeping the original coordinates 
> is unnecessary overhead.
> 
> I doubt reusing just a simple path with different transformations is a 
> significant use case that justifies this overhead, and most 
> implementations seem not to support it anyway.
> 
> So I would prefer to keep it simple and to see the spec reflect the 
> current reality over having both or incompatible changes in 
> implementations.

On Tue, 17 Apr 2007, Jordan OSETE wrote:
> 
> Now that you say it, it's true that if the web application draws it 
> once, drawing it again is as simple as putting the drawing code in a 
> separate function and calling it again, with a different transform 
> matrix set.

Per the above discussion, I haven't added anything to store paths yet.


On Sun, 15 Apr 2007, Stefan Haustein wrote:
>
> Anyway, now that you mention it, we really need a way to retrieve the 
> current transform matrix. Like the current point, it is something that 
> already is in the browser's memory, so a function returning an array 
> would be enough.

There's still no way to _get_ the transformation matrix, but you can not 
_set_ the transformation matrix now, which should be of help here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'