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

On Feb 28, 2014, at 6:18 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:

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

Your example looks very convincing. I admit that I misinterpreted your previous message. My apologies.

The suggested Polar Decomposing was introduced to this list by Ken Shoemake before [1][2]. The general overhead for implementations seems reasonable and comparable with the current slerp based approach in the spec.

Ultimately it is up to the UAs if they want to follow the Polar Decomposing approach or the current one in the spec. In the past UAs tended to prefer the decomposing code in Safari because content already relied on it.

I am willing to change the decomposing code to any preferred algorithm. Note that the decomposing code is the last resort for transform list interpolations at the moment.

Greetings,
Dirk

[1] http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0014.html
[2] http://research.cs.wisc.edu/graphics/Courses/838-s2002/Papers/polar-decomp.pdf

> 
> Benoit
> <transform-animation-not-covariant.html>

Received on Friday, 28 February 2014 17:58:52 UTC