Re: [css-transforms] transform interpolation rules should operate better on their own results

On Feb 27, 2014, at 5:30 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:

> I followed this link, http://dev.w3.org/csswg/css-transforms/#matrix-interpolation, and it made me sad.
> 
> When interpolating between two matrices, each matrix is decomposed into the corresponding translation, rotation, scale, skew and (for a 3D matrix) perspective values.
> 
> This makes no sense in any geometric way, i.e. in any coordinate-independent way. Matrices can be decomposed in such a way, but graphics don't really care about matrices --- graphics care about transformations that can be represented by matrices in particular coordinate systems. The only matrix operations that graphics wants to use, then, are matrix transformations that have a coordinate-independent meaning. For example, matrix product has a coordinate-independent meaning as composition of transformations. But "decompose a matrix into the corresponding translation, rotation, scale, skew and perspective values" has no coordinate-independent meaning.

Could you elaborate what you mean with coordinate independent? A transformation matrix transforms the current coordinate space. A transformation matrix viewed in an isolation is independent of coordinates. The coordinate system however is defined by the current transformation matrix. In a regular, cartesian coordinate system that we use for markup languages, this transformation matrix is the identity transform. Transformation functions like translate(), rotate() and others can be represented by transformation matrices.

A slerp based decomposing approach as for 3D matrices in CSS Transforms is a widely used and recognized way for interpolation. As is the euler based approach for 2D matrix decomposing. Both decomposing algorithms produce reasonable and pleasant results. The intermediate decomposing values can be seen as translation, rotation, scale and skew values. For 3D matrix decomposing we have some slerp parameters as quarternion values.

Greetings,
Dirk

Received on Thursday, 27 February 2014 16:55:11 UTC