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

2014-02-27 11:54 GMT-05:00 Dirk Schulze <dschulze@adobe.com>:

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

Here is a visual demonstration of this issue:
http://people.mozilla.org/~bjacob/transform-animation-not-covariant.html
(Also as attachment to this email).

Explanations are given in that page.

I hope that the problem is easy for everyone to see now.

Benoit