From: Dirk Schulze <dschulze@adobe.com>

Date: Mon, 4 Jun 2012 14:16:37 -0700

To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>

CC: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, "www-svg@w3.org" <www-svg@w3.org>, "public-fx@w3.org" <public-fx@w3.org>

Message-ID: <B6A713AD-5C5F-446A-A5AC-056CC3322957@adobe.com>

Date: Mon, 4 Jun 2012 14:16:37 -0700

To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>

CC: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, "www-svg@w3.org" <www-svg@w3.org>, "public-fx@w3.org" <public-fx@w3.org>

Message-ID: <B6A713AD-5C5F-446A-A5AC-056CC3322957@adobe.com>

On Jun 4, 2012, at 12:21 PM, Cyril Concolato wrote: > Hi Dirk, > > Le 6/4/2012 9:06 PM, Dirk Schulze a écrit : >> On Jun 4, 2012, at 11:58 AM, Cyril Concolato wrote: >> >>> Hi all, >>> >>> This thread is just too long for me at the moment, but I repeat what I >>> said. I think that the neutral element for by animations should be the >>> identity matrix. There is no mathematical problem. Adding a zero scale >>> (or rotate, or translate, or skew, ...) is equivalent to post >>> multiplying with the identity matrix. >> I thought it was a typo the last time. But scale(0) is definitely not the identity matrix. >> >> Identity transform is: >> >> | 1 0 0 | >> | 0 1 0 | >> | 0 0 1 | >> >> While scale(0) or scale(0,0) is equivalent to: >> >> | 0 0 0 | >> | 0 0 0 | >> | 0 0 1 | >> >> according to SVG 1.1. > Up to this point, I agree with you. > >> >> The identity transform is the neutral element for multiplication, not for addition. > That's where I differ. The neutral element for addition of a scale > transform is 'e' such that for all X: > scale(X+e)=scale(X) > So yes e=0 but this does not mean a matrix of zeros. No it does not. Olaf's point was that you shouldn't compare it to matrices. Because, like you said, it depends on the value for 'e'. 'e' is zero for all transformation functions. This doesn't mean that it results in a identity matrix or something different. For translate, rotate, skewX and skewY it is true. For scale it isn't (you already agreed to that previously in this mail). With a view to the second part of your comment. Hm. That is what SMIL says about by-animation: "" Specifying only a by value defines a simple animation in which the animation function is defined to offset the underlying value for the attribute, using a delta that varies over the course of the simple duration, starting from a delta of 0 and ending with the delta specified with the by attribute. This may only be used with attributes that support additive animation. "" And further: "" Normative: A by animation with a by value vb is equivalent to the same animation with a values list with 2 values, the neutral element for addition for the domain of the target attribute (denoted 0) and vb, and additive="sum". Any other specification of the additive attribute in a by animation is ignored. "" This is what SVG Animation says about additive behavior: "" The animation effect for ‘animateTransform’ is post-multiplied to the underlying value for additive‘animateTransform’ animations ... "" Let's take an example with 'animateTransform': <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <rect width="100" height="100" transform="scale(1)"> <animateTransform attributeName="transform" type="scale" by="1" dur="3s"/> </rect> </svg> According to the normative sentence on SMIL 3 Animation, this is equivalent to: <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <rect width="100" height="100" transform="scale(1)"> <animateTransform attributeName="transform" type="scale" values="0;1" additive="sum" dur="3s"/> </rect> </svg> The underlying value is scale(1). The value of the animation gets post multiplied. So we get an animation of: scale(1)*scale(0) is equal to | 1 0 0 | | 0 0 0 | | 0 0 0 | | 0 1 0 | * | 0 0 0 | = | 0 0 0 | | 0 0 1 | | 0 0 1 | | 0 0 1 | to scale(1)*scale(1) (which is equal with the multiplication of two identity transforms and therefore is a identity transform as well) > If you decompose scale(X+e) with a product of scales: > scale(X+e)=scale(X)scale(e')=scale(X) for all X, then e'=1. > Applying a by animation of scale is post-multiplying with a scale > transform and the neutral element is the identity. Now I don't know what you mean with X. If X is the value of the 'by' attribute, then I don't know what you mean with this formula. If X is there underlying value, than it is not what SMIL animation and SVG Animation says. An example for length values would be: <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <rect width="100" height="100"> <animate attributeName="width" by="100" dur="3s"/> </rect> </svg> which is equivalent to: <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <rect width="100" height="100"> <animate attributeName="width" values="0;100" additive="sum" dur="3s"/> </rect> </svg> If the initial value is X and the by value is Y, it leads to an animation from X + 0 to X + Y. In total 100 to 200. But 'animateTransform' (and animation of transforms in general) is different. The additive behavior is defined by post multiplying the resulting transforms. Therefore it is not scale(X+0) to scale(X+Y). But scale(X)+scale(0) to scale(X)*scale(Y) (if the initial transform is scale(X)). 'animateTransform' just has a list of scalars as values. That is why SVG Animation doesn't need to specify more. This is a bit different on 'animate', where you have transform functions as value. Here an example with 'animate' (note that this does not work in current UAs): <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <rect width="100" height="100" transform="scale(1)"> <animate attributeName="transform" by="scale(1)" dur="3s"/> </rect> </svg> Transforming this into the values wording it could look like: <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <rect width="100" height="100" transform="scale(1)"> <animate attributeName="transform" values="X;scale(1)" dur="3s"/> </rect> </svg> And again. Because additive behavior is specified by post multiplying transforms, it would be scale(1)*X to scale(1)*scale(1). But how does X (the neutral element to addition) look like? We don't have scalars as values, but transform lists. So it needs to be defined. CSS Transforms tries to imitate the behavior of 'animateTransform', by defining the neutral element explicitly with the certain transform function and the neutral element of addition to the scalars in it. Therefore, the neutral element above is scale(0). Greetings, Dirk > > >> For addition it is the zero matrix: >> >> | 0 0 0 | >> | 0 0 0 | >> | 0 0 0 | >> >> But that isn't even the point of Olaf and SMIL. SMIL says that the neutral element for addition according to a scalar is searched. > That's not really contradictory with what I said above. > >> That is why animateTransform just takes scalars as values. So according to SMIL, it should really be 0 for translate, scale, rotate, skweX and skewY. > Yes, 0 as in scale(X+0)=scale(X). >> >> But that does not prevent us from changing it. Would just be one more difference to SMIL :). > I don't think this would be the case. > > Cyril >> >> Greetings, >> Dirk >> >>> Cyril >>> >>> Le 6/2/2012 12:07 AM, Dirk Schulze a écrit : >>>> On Jun 1, 2012, at 1:51 AM, Dr. Olaf Hoffmann wrote: >>>> >>>>> Cyril Concolato: >>>>> >>>>> >>>>>> [CC] Adding 1 in the scale transformation means going from scale(X) to >>>>> scale(X+1), therefore the neutral element is scale(0) which is the identity >>>>> matrix. >>>>> >>>>> scale(0) is not the identity matrix, this is obviously scale(1,1), >>>>> because >>>>> (0,0) = scale(0,0) * (x,y) and for arbitrary x,y it is of course in most >>>>> cases (x, y)<> (0,0); scale(0,0) is no representation of the identity matrix. >>>>> but >>>>> (x,y) = scale(1,1) * (x,y); scale(1,1) is a representation of the identity >>>>> matrix. >>>>> >>>>> On the other hand the identity matrix has nothing to do with additive >>>>> animation or the neutral element of addition, therefore there is no >>>>> need, that it is the same. The identiy matrix is the neutral element >>>>> of matrix multiplication, what is a completely different operation. >>>> Like Cyril wrote, it was just a typo from him. >>>> >>>>> For the operation of addition of matrices M: 0:=scale(0,0) represents >>>>> a neutral element M = M + 0 = 0 + M, but typically this is not very >>>>> important for transformations in SVG or CSS. >>>> I added a first draft of the definition for the 'neutral element of addition' to CSS Transforms [1]. The only problem that I see is with 'matrix', 'matrix3d' and 'perspective'. According to the definition of SMIL the values should be 0 (list of 0) as well. This would be a non-invertible matrix for 'matrix' and 'matrix3d' and a undefined matrix for 'perspective'. The interpolation chapter for matrices does not allow interpolation with non-invertible matrices [2]. Therefore 'by' animations on these transform functions will fall back to discrete animations and cause the element not to be displayed for half of the animation [3]. >>>> >>>> Of course it could be possible to linearly interpolate every component of a matrix, but since this is not the desired effect for most use cases, we use decomposing of matrices before interpolations. >>>> >>>> [1] http://dev.w3.org/csswg/css3-transforms/#neutral-element >>>> [2] http://dev.w3.org/csswg/css3-transforms/#matrix-interpolation >>>> [3] http://dev.w3.org/csswg/css3-transforms/#transform-function-lists >>>> >>>>> The scale function could have been defined in the passed in >>>>> such a way, that the identity matrix results from the neutral >>>>> element of addtion, this works for example in this way: >>>>> scale(a,b) means scaling factors exp(a) and exp(b). >>>>> But this would exclude mirroring and is maybe more >>>>> difficult to estimate the effect for some authors. >>>>> A Taylor expansion approximation by replacing >>>>> exp(a) by (a+1) could save the mirroring, but not the >>>>> intuitive understanding of scaling. >>>>> Therefore there is no simple and intuitive solution to >>>>> satisfy all expectations - and too late to change the >>>>> definition anyway. >>>> I would also think it gets to complicated for most authors. >>>> >>>>> Olaf >>>>> >>>> Greetings, >>>> Dirk >> >Received on Monday, 4 June 2012 21:20:09 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 22 June 2015 03:33:47 UTC
*