[whatwg] Canvas feedback (various threads)

[David Flanagan]

Ian Hickson wrote:
> On Mon, 19 Jul 2010, David Flanagan wrote:
>> Even changing the argument names to neutral a,b,c,d,dx,dy would be
>> better than what is there currently.
> 
> Done.
> 

Thanks


> On Mon, 19 Jul 2010, David Flanagan wrote:
>> While I'm harping on the transform() method, I'd like to point out that
>> the current spec text "must multiply the current transformation matrix
>> with the matrix described by..." is ambiguous because matrix
>> multiplication is not commutative.  Perhaps an explicit formula that
>> showed the order would be clearer.
>>
>> Furthermore, if the descriptions for translate(), scale() and rotate()
>> were to altered to describe them in terms of transform() that would
>> tighten things up.
> 
> Could you describe what interpretations of the current text would be valid
> but would not be compatible with the bulk of existing implementations? I'm
> not sure how to fix this exactly. (Graphics is not my area of expertise,
> unfortunately. I'm happy to apply any proposed text though!)
> 

I think that the sentence "The transformations must be performed in 
reverse order" is sufficient to remove the ambiguity in multiplication 
order.  So the spec is correct (but confusing) as it stands, except that 
it doesn't actually say that the CTM is to be replaced with the product 
of the CTM and the new matrix.  It just says multiply them.

I suggest changing the description of transform() from:

> must multiply the current transformation matrix with the matrix described by:

To something like this:

must set the current transformation matrix to the matrix obtained by 
postmultiplying the current transformation matrix with this matrix:

a c e
b d f
0 0 1

That is:

              a c e
CTM = CTM *  b d f
              0 0 1

Changing translate(), scale() and rotate() to formally define them in 
terms of transform() would be simple, and the current prose descriptions 
of the methods could then be moved to the non-normative green box.  The 
current descriptions suffer from the use of the word "add" near the word 
"matrix" when in fact a matrix multiplication is to be performed, but I 
don't think they can be mis-interpreted as they stands. I'd be happy to 
write new method descriptions if you want to tighten things up in this 
way, however.

	David