[whatwg] Canvas feedback (various threads)

David Flanagan david at davidflanagan.com
Wed Aug 11 14:42:28 PDT 2010

```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

```