Re: [css3-transforms] neutral element for addition - by animation

Hi Olaf,

On Jun 3, 2012, at 6:06 AM, Dr. Olaf Hoffmann wrote:

> Dirk Schulze:
>
> ...
>>>
>>> This applies as well for scale(0,0), scale(0,y), scale(x,0) etc,
>>> therefore no really new problem.
>>
>> No. As long as the third (and second) rule of [1] apply to the transform
>> function list, these transform functions can get interpolated numerically,
>> as described by [2].
>
> [1], section 17 talks about the value 'none'.
> Obviously for all of these transform types one can simply
> interpolate between values for animateTransform, because
> they are always of the same type and one simply has to
> interpolate affine between numbers as described in SMIL.
> No specific rule required, no new problem appears.
> (We need to discuss to-animations separately, related
> to your current email about the issue
> 'about animate and animateTransform')
Just speaking about the behavior of 'animateTransform' I would agree. But the same is true for the same use cases on 'animate':

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect width="100" height="100">
    <animate attributeName="transform" attributeType="XML"
                      by="scale(1)" dur="5s" fill="freeze"/>
  </rect>
</svg>

The example works because of the section you referenced. The same is true for the other supported transform functions: 'translate', 'rotate', 'skewX' and 'skewY'. 'matrix' is _not_ supported by 'animteTransform' (neither SVG 1.1 nor SVG 1.2 tiny). Because of the reasons I mentioned before: The  numerical interpolation of each value in the list of matrix, seldom produces reasonable _visual_ results. I know of one of the developers from Batik that they got the same experience on one of their own tests. Therefore: CSS Transforms allows the same kind of animations like you can receive with 'animateTransform'.

We are talking about the behavior beyond 'animateTransform'.

>
> If another interpolation method like decomposition introduces
> a problem for some normal values as zero, this is a problem
> of this interpolation method, not of these zero values and not
> specific for by-animations, because those are defined
> to be equivalent to values animations anyway.
This is a question of definition.

> scale(0,0) and matrix(0,0,0,0,0,0) describe the same matrix.
If you have just scale(0, 0) yes. But does for instance rotate(720) describe the same as matrix(1 0 0 1 0 0)? According to the mathematical description [1], yes! And still, they are not bidirectional. Using a matrix to describe a transform function can lead to a lost of information. This is from interest in particular on interpolation! Therefore, the argumentation with matrices is not solid as well.

> If you start to apply the decomposition method to this with
> the CSS transform animation, for example with animation
> from scale(0,0) to rotate(180) you will get the same or
> similar problem, probably even the same result as for
> from matrix(0,0,0,0,0,0) to rotate(180) - the decomposition
> pseudocode is too complex, that I can really predict without
> numerical calculations, whether the result is the same, but if it is not
> much worse than expected, it should be the same ;o)
> On the other hand, if you animate from
> scale(0,0) to scale(-1,-1) this is the same as
> to animate from
> matrix(0,0,0,0,0,0) to matrix(-1,0,0,-1,0,0),
> therefore no different situation and no need for
> decomposition with these variants.
Like written in the comment above. Just because a transformation function can be described by a matrix (with potential lost of information), they are not the same. Even so, if we decompose a 4x4 matrix, it is always possible not to find a combination of transform functions with rotate, translate, shear and scale that describes the current matrix. I think this is what you meant with 'unstable' before. To avoid these situations, the specification defines when a matrix can be decomposed. For CSS Transforms, the matrix must be invertible. This is consistent with all decomposing variants I found so far.

>
>>
>>> I got the impression from the previous discussion, that this quaternion
>>> approach could avoid the nasty problem of matrix inversion, but still
>>> the related section contains such nasty implications, which cause
>>> such problems.
>>
>> The quaternions try to solve other problems like the Gimbal Lock, a side
>> product of the decomposing of matrices. A problem that can occur with euler
>> angels.
>
> Well, then this change still means, the CSS method for interpolation
> is not good enough, because it still requires inversion.
It is defined to require invertible matrices, yes. See comment above. That does not mean it is not good enough. It just can't decompose every matrix into an equivalent list of scale, rotate, shearing and translation. This is the nature of the decomposing used by the implementations.

>
>>
>>> As long as this is not stabilised by avoiding inversions,
>>
>> It is unclear to me what "stabilized" means for you :)
>
> For example:
> a) No inversion causing artifacts
> (for example additional to the problem of non invertable
> matrices this can cause often larger numerical inaccuracies,
> if the determinant is 'close' to zero or the matrix has a
> structure, that causes problem for numerical inversion -
> this is, what one gets served in one of the first lessons
> about numerical mathematics at university.)
Of course that can happen. This is an issue of implementations (or machines the code is running on).

> b) The effect of the interpolation is hardly to predict for
> the author of an document.
> Even looking on the pseudocode of this method,
> I have no idea, what will be the result of an interpolation
> between two arbitrary matrices and I have no intuitive
> idea, how this result could be related to what I will get,
> therefore I simply do not know, which matrices I have
> to note for this method to get an intended effect,
> therefore it is much simpler to get the effect
> approximately with this method of animating
> xlink:href of use with 20 shapes per second than
> to gues what might happen with this decomposition.
> Authors need to 'implement' the decomposition themselves,
> to estimated, what the effect of an animation is - which
> authors will do this, typically instead they will simply try to
> avoid this decomposition at all to get simpler predictable results.
You can definitely not be sure what you get on choosing arbitrary matrices with a numerical interpolation. This can lead to temporarily situations that can not be described by rotate, scaling, translating and shearing and often leads to flickers that you definitely not want. An author wants a smooth animation. Just because it is mathematical clear how numerical interpolation looks like, does not mean that you get the visual result you expect. This is mostly not the case for pure numerical interpolation. That is why CSS Transforms, and in particular the implementers, chose decomposing in the first place.

>
> ...
>>
>> There is a whole section in the spec [4] that describe how to apply
>> perspective and how to multiply nested transformation functions. In general
>> they try to specify the current behavior of current browsers.
>
> As already discussed, there is still missing the mathematical
> description, how the matrixes of section 21 are related to
> the effect of a transformation. I think, this will be added
> in the future as already promised. After this is done,
> section 6 will be nice to help to understand this.
The mathematical formulas are just syntactic sugar. The behavior is already described in the prose text. I hope that I can add the formulas next week. However, the behavior is specified already.

>
>>
>>> As long as the behaviour is not defined,
>>> there is nothing to discuss or to implement for 3D transforms ;o)
>>> In doubt, indeed one has to define a specific rule once it is
>>> defined, how such 3D-matrices are applied.
>>> But looking on the matrices, implicating already some
>>> concept, my assumption is, one cannot avoid a problem
>>> here.
>>
>> 3D transforms are already implemented. The current behavior needs to be
>> specified now.
>
> This looks like the wrong order again - obviously one should first specify,
> what has to be done, after this one can implement, what is specified.
> Of course a test implementation can help, but of course this should not
> be available for the public, else the complete draft/recommendation
> is superfluous, if arbitrary things are implemented and later it is
> just noted a history of implementation bugs and aberrations ;o)
This is the way how industry works mostly :). First the implementation then the specification that specifies the existing behavior. The other way around doesn't need to be better.

>
>>
>> I have not checked additive transform behavior on matrices for SVG
>> Animations on Opera so far. At least for CSS Transforms start and end
>> matrix must be invertible, otherwise the interpolation does not work.
>
> I did not check this as well, years ago somebody mentioned in the www-svg
> list, that they implemented it, I just tested, that this is true, no details -
Maybe Opera changed the implementation. However, it is not possible to use the type 'matrix' on 'animateTransform' on Opera, FF, WebKit or Batik from the tests here.

> presumbly the implementation is not related to the CSS drafts,
> that occur now, therefore I assume they simply interpolate between
> the values without introducting inversion complications, because if
> you interpolate with animateTransform between two matrices
> with the SMIL concept, you just have to interpolate between two
> lists of numbers of the same lengths, this is simple and available
> already for several other attributes or properties - nothing really
> new to implement, one only has to ignore, that the transform
> type 'matrix' is not animatable in SVG 1.0, 1.1 and 1.2, this can
> even happen 'by accident' - the filter chapter has more complex
> values, which are animatable ;o)
As someone who implemented SVG Filters and the animation of filters, I strongly disagree. This is far easier ;). Especially because you don't deal with affine transforms. I agree that animating of single transform functions is easier to implement and to specify. On the other hand, animation of transforms with 'animate' is a lot more powerful and requested by authors. Of course this has more edge cases the implementation has to deal with.

>
>>
>>> It causes no problem to apply such matrices without animation to
>>> arbitrary content, therefore it can be expected, that an animation
>>> method is chosen, that does not introduce problems in areas, where
>>> are no problems. Fortunately we know already a method, that causes
>>> no such additional problem. This is described in SMIL. Of course,
>>> there can be others as well.
>>
>> If you tested additive matrix interpolations on SVG Animations with Opera,
>> and if it gave you a smooth interpolation, then maybe because every value
>> of the matrix got interpolated numerically. Like I said, I did not check it
>> myself. However, for CSS Transforms it was decided, that this 'mostly' does
>> not give you reasonable results.
>
> Due to the inversion problem, the decomposition methods does not
> provide resonable results - and of similar relevance, no simply predictable
> results (maybe similar to a surprise egg (Kinder surprise,
> german: 'Überraschungsei', don't know how to translate) …
Makes me hungry :)

> Maybe the decision makers used only examples without a
> relevant use case?
> Obviously if you calculate the matrices for
> translate(20,-50) rotate(30) translate(-20,50) and
> translate(-20,50) rotate(770) translate(20,-50)
> and interpolate between the matrices, you will not get a rotation
> of 750deg with a moved rotation center, but if you note the matrices
> as animation values, you do not expect a rotation anyway,
> else you did not understand matrices and your expectations do not
> really matter for the result and such an example is no meaningful
> test case for the decision ;o)
Authors expect a rotation by 740 degree. And yes, with matrix interpolation you would not see two turns. But it is easy to address both behaviors.

>
>> Therefore CSS Transforms uses decomposing.
>
> And as we can see - it fails, if the matrices are non invertable, what
> has nothing to do with the values to be interpolated between, just
> with this interpolation method.
It does not work for non-invertible matrices, yes.

>
>> The decomposing code in current browsers can not deal with  non-invertible
>> matrices.
>
> As already mentioned, this indicates, that the methods needs to be
> improved and stabilised to avoid such strange artifacts.
See comments above.

>
> ...
>>
>> For daily serious use you would use transform functions that are
>> interpolatable by [2]. These animations make most sense, give you
>> reasonable results and fulfill >90% of all use cases.
>
> You mean with values lists, the same structure for every value,
> therefore no decomposition is required? Obviously these are
> the main use cases for animated transforms and we need
> no decomposition for them. Therefore we need to care
> only about use cases, that have either to do with interpolation
> between a list of matrices or for lists with mixed structure.
> I think, there is no disagreement about the majority of
> use cases, where you have a list of values of the same
> type (only available currently in SVG) or for the CSS
> concept to have values with transform lists all of the
> same structure - obviously this is meaningful and compact
> to be able to apply the animation to the list items.
> But if you allow in animateTransform now to interpolate
> between matrices, this is still ony type for the animation,
> no new problem occurs.
I won't specify the behavior of 'animateTransform' in CSS Transforms. For SVG 1.1 the behavior won't change.

>
> Looking at the method, I think, if one has an arbitrary
> amount of transforms like scaling, translation, rotation, skewing
> multiplied to a matrix, the decomposition of such a matrix
> is not even able to decompose the matrix to the same
> list, this means, finally the complete process is not
> bijective.
No it is not. But this is a general problem and not specific to the decomposing algorithm.

> This means finally, one cannot even compress
> longer lists to a matrix so reduce the file size, if the
> animation effect matters in detail.
Correct. It can happen that you don't get exactly the same interpolation on matrices as with the list of transform functions. But you definitely don't get the same behavior with numerical interpolation of matrix values more often then with decomposing.

>
> Therefore the 'core use case' for authors seems to be
> to avoid, that the decompostion ever takes place ;o)
For sure not.

>
> Can you list 10 meaningful use cases for the CSS
> decomposition method to interpolate between
> two matrices?
See comment above: Smooth animations on interpolation between matrices with most sense full visual interpolation behavior! Most authors don't care about mathematical correct solution, which depends on the definition of mathematical correct anyway.

Greetings,
Dirk

Received on Sunday, 3 June 2012 15:44:37 UTC