- From: Benoit Jacob <jacob.benoit.1@gmail.com>
- Date: Thu, 27 Feb 2014 11:30:36 -0500
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: public-fx@frink.w3.org
- Message-ID: <CAJTmd9odJbbQVgjzTBjejf_wwFjJ-4ThrbQYx1rf3Rh=8HjeRQ@mail.gmail.com>

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

Received on Thursday, 27 February 2014 16:31:39 UTC