From: Chris Marrin <cmarrin@apple.com>

Date: Mon, 30 Mar 2009 16:01:18 -0700

Message-id: <33D1DED9-84B6-48EA-9238-6D8347DB2589@apple.com>

To: www-style@w3.org

Date: Mon, 30 Mar 2009 16:01:18 -0700

Message-id: <33D1DED9-84B6-48EA-9238-6D8347DB2589@apple.com>

To: www-style@w3.org

On Mar 28, 2009, at 11:17 AM, Dr. Olaf Hoffmann wrote: >> ...We're telling you we came up with this approach and documented it >> because it is what we found to be best. You might not agree, but you >> also have not actually tried it, nor given us any examples that are >> impossible/broken with our current approach. >> > > As I already wrote, I tried it, therefore it is not helpful for the > discussion > to claim, that I did not try it, because I know best, what I tried > and what > not. What I tried is the interpolation between two matrices A, B > with the current Matrix C, time t from 0 to 1: > > (*) C(t) = Bt + (1-t)A > > And you noted already an example on your own, which makes a > difference: > > "Imagine animating from [0.707 -0.707 0.707 0.707 0 0] to [0.707 0.707 > -0.707 0.707 0 0], which is an animation from 45 degrees to -45 > degrees. Without decomposition at 50% you have [0.707 0 0 0.707 0 0], > which is a rotation of 0 degrees (this is correct) but with a scale of > 0.707 (definitely incorrect)?" > > Due to the formula above what you noted to be incorrect is correct > and what I need. > To fix this with an implementation of decomposition I have to provide > a large list of matrices for the animation, that the effect of > decomposition > becomes neglectible. > ... > No, IFS are often pretty simple for the author, most of them can be > simply hand coded. This is the advantage of vector graphics. > And if both is available, lists of 'simple' transformations like > rotation, > translation, scaling, skewing and simple matrices, there is no need to > calculate something for authors. > This happens only, if either the simple transformations like rotation > would not be available or the matrix interpolation is not available, > in both cases authors have to start nasty number crunching to > realise/approximate the not available variant with the > available variants. > For IFS (with SVG, for (X)HTML this is possible too, but not > trivial, because there is nothing like the use element; object or > iframe maybe, but with this there is no control on the depth > or recursion - ugly for the viewer) the files often are only a few > kilobyte, but the viewer has to crunch for a few seconds to get > the result. Ok, I think I'm starting to understand where the disconnect lies. I believe you are very cleverly using the 4x4 matrix from the CSSMatrix object to solve a set of simultaneous equations. My knowledge of fractals is very weak, so forgive me if my thinking is off, but that's what it looks like. That's great and matrices are very well suited to such a task. The CSSMatrix is in fact a general 4x4 matrix system with a set of mathematical functions which make it possible for you to make your Iterated Function Systems. The problem (and the disconnect) is not with CSSMatrix at all. It's when you apply it to the -webkit-transform CSS property. That property expects and operates on a _transformation_ matrix. And the operations that property performs are related to using that matrix to do transformations. Therefore it has certain constraints, the most significant of which is that the matrix must be invertible. This is because we use the matrix to do (among other things) hit testing, which requires inversion to map coordinates into the parent system. So as soon as you use the generalized 4x4 matrix from CSSMatrix in the -webkit-transform property, you constrain it. Another of these constraints comes about when you animate the -webkit-transform property. You could do a linear interpolation of the matrix elements, but this would usually give authors surprising and often puzzling behavior. Another way is to decompose the matrix into a translation, rotation, skew and perspective, animate each separately according to what is natural for the type (e.g., linear interpolation for translation, spherical linear interpolation for rotation), and then recompose into a 4x4 matrix. Given the purpose of the property (transformation), and the audience it is intended for (web content developers) this allows the author to avoid puzzling outcomes. I think this is the most logical way to accomplish the task of animating the -webkit-transform property. Your use is different. You're solving a set of linear equations, and as such your needs are different. For you a purely linear transformation makes the most sense. But that goes beyond the current definition of the transformation matrix in the proposal. I think your proposal is a good one and would provide some interesting use cases. But I think it is a different proposal. We have discussed an animation API, which would give you more control over animations than the declarative form available in CSS. Perhaps that would be a more appropriate place to incorporate linear interpolation of a 4x4 matrix. Such an API could disassociate a given data type from a particular set of properties to which it might apply. So the constraints on how those data types are animated could be more flexible. Defining a linear interpolation for a matrix would make sense in that context. Until then, I think it makes the most sense to use CSSMatrix to compute and maintain your IFS data and then use JavaScript to iterate it as needed. With the great performance of the WebKit JS engine, I think that's entirely practical. ----- ~Chris cmarrin@apple.comReceived on Monday, 30 March 2009 23:01:59 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 2 May 2016 14:38:25 UTC
*