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

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
> <http://dev.w3.org/csswg/css-transforms/#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.

To put this in concrete terms, this means that if an author uses such a
matrix interpolation algorithm, he will see that his matrix interpolation
behaves totally differently if he applies certain global affine
transformation to his scene. An author would naturally expect that "the
interpolation in a transformed scene is just the transformed interpolation"
which is exactly asking for interpolation to be coordinate-independent.

A reasonable coordinate-independent interpolation method is to interpolate
polar decompositions.
http://en.wikipedia.org/wiki/Polar_decomposition
http://en.wikipedia.org/wiki/Polar_decomposition
A quick google search suggests that that has been used in computer graphics
animations before:
http://research.cs.wisc.edu/graphics/Courses/838-s2002/Papers/polar-decomp.pdf

I've made a similar argument before on a different spec:
http://lists.w3.org/Archives/Public/public-fx/2013JanMar/0174.html . I
didn't realize or remember that the same problem existed in CSS Transforms.

Benoit


2014-02-26 18:48 GMT-05:00 L. David Baron <dbaron@dbaron.org>:

> I'm sending this feedback as a result of a Mozilla bug report, filed
> by an author who saw bad transform interpolation behavior:
> https://bugzilla.mozilla.org/show_bug.cgi?id=977311
>
> http://dev.w3.org/csswg/css-transforms/#interpolation-of-transforms says:
>
>   If from- and to-transform have the same number of transform
>   functions, each transform function pair has either the same name,
>   or is a derivative of the same primitive.
>
> Then
> http://dev.w3.org/csswg/css-transforms/#interpolation-of-transform-functions:
>
>   The transform functions matrix(), matrix3d() and perspective() get
>   converted into 4x4 matrices first and interpolated as defined in
>   section Interpolation of Matrices afterwards.
>
> This means that if you interpolate two lists that consist of:
>   perspective() rotateY()
>   perspective() rotateY()
> you get an interpolation result that is:
>   matrix3D() rotateY()
>
> When you try to interpolate that result with another value of the form:
>   perspective() rotateY()
> we fall back to the "Lists don't match" path in the first quote.
>
>
> This is important for reversing of partially-completed transitions.
> If an author has
>   div {
>     transition: transform;
>     transform: perspective(800px) rotateY(180deg);
>   }
>   #container:hover div {
>     transform: perspective(800px) rotateY(300deg);
>   }
> then if the transition is interrupted partway through, it should
> reverse the same way it came (per-function interpolation) rather
> than reversing in an entirely different way (matrix interpolation
> fallback).
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>              Before I built a wall I'd ask to know
>              What I was walling in or walling out,
>              And to whom I was like to give offense.
>                - Robert Frost, Mending Wall (1914)
>