Re: Canvas path transformations

On Wed, 16 Jan 2008, Philip Taylor wrote:
> 
> Some rough comments on the recent canvas changes (which made 
> transformations take effect when paths are constructed, rather than when 
> they're drawn, for compatibility with Firefox and Safari):
> 
> 
> "The transformation matrix can become infinite, at which point nothing 
> is drawn anymore." - that doesn't really make sense now, since it's not 
> a rule that can be applied when drawing. You could make the 
> transformation matrix infinite, then make it finite again, then create 
> some path, then fill, and it should probably draw the path. Or you could 
> make it infinite, create a bit of path, make it finite, create more 
> path, then draw, and it should probably draw just the second bit of 
> path.
> 
> At least that's what Safari does. Firefox throws exceptions whenever you 
> pass in infinity to a method. I wouldn't mind if it was specified to 
> always throw exceptions when passing infinity/NaN to a method, or maybe 
> if it was explicitly undefined - implementation details already mean you 
> can't get theoretically correct results when scaling by e.g. 10^38, so 
> it's not much worse if infinity is treated the same way...

I've changed the way infinity is handled. Let me know if the new text is 
better.


> createLinearGradient, createRadialGradient: How are those coordinates 
> affected by the CTM?

Fixed.


> "The coordinates given in the arguments to these methods must be 
> transformed according to the current transformation matrix before 
> applying the calculations described below and before adding any points 
> to the path." - that is true for moveTo, lineTo, quadraticCurveTo, 
> bezierCurveTo. It is not true for the others:

I've changed the way this is worded. Is it better? I'm reluctant to 
rewrite all the text to be pedantically correct here. :-)


> "The stroke() method must stroke each subpath of the current path in 
> turn, using the strokeStyle, lineWidth, lineJoin, and (if appropriate) 
> miterLimit attributes." - that should also say something like "The line 
> width must be scaled by the current transformation matrix." (that's not 
> really true (it needs to at least be skewed as well, and I'm not sure of 
> the exact details), but stroke drawing is totally underdefined anyway 
> and so there's not much point being precise here now), since I think 
> it's clearer to say it here (as it's directly relevant to the outcome of 
> stroke()) rather than hidden in the '3.14.11.1.11. Drawing model' 
> section. (Also, 'Drawing model' shouldn't need to say that fill/stroke 
> styles etc are honoured, since the definitions of stroke() and fill() 
> already say that.)

This changed a bit recently too, it now says "the stroke must itself also 
be subjected to the current transformation matrix". Is that ok?


> "Paths, when filled or stroked, must be painted without affecting the 
> current path, and must be subject to transformations, shadow effects, 
> global alpha, clipping paths, and global composition operators." - 
> remove the "transformations" since the paths aren't transformated when 
> filling or stroking.

Clarified.


> "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." - delete that since it's lying now.

Gone.

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

Received on Saturday, 2 February 2008 01:19:18 UTC