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

Many thanks for the links; I didn't realize at all that Ken Shoemake had
recently written to this list about this. I will reply on that thread.

Benoit


2014-02-28 12:58 GMT-05:00 Dirk Schulze <dschulze@adobe.com>:

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