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

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

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.
scale(0,0) and matrix(0,0,0,0,0,0) describe the same matrix.
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.

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

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

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

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

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

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

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

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

...
>
> 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. Even for the CSS concept,
as long as the author does not 'corrupt' the list item
structure of such a transform list, no new problem
occurs, if such an authors uses matrices.
Only if the transform lists are not separable anymore
into the same structure for each animation value, a
problem occurs for the CSS approach, the decomposition
might be a solution or an option. Else there is no need
for this.

I have no other use case in mind for animated interpolation between
matrices as the need to have a somehow generated time dependent
transform matrices, that have to be represented as a values list with
a finite number of values. For this use case the interpolation between
these values has to be simple, fast and stable and without artificial
complications introduced by the interpolation method, not under
control of the author. With the affine interpolation from SMIL it is
relatively simple to predict, how many values per second are
required to get a sufficient approximation, typically this will be
clearly less than 20. With the CSS decomposition method, I
simply don't know, because the results are not predictable -
maybe you need even more than those 20 with the result,
that you can forget this method at all.

If you talk about >90% of use cases, this CSS decomposition
is good for, you should be able to list at least ten use cases, 
this method is good for, because I was able to mention one
important use case for the simple affine interpolation ;o) 
Currently my list for decomposition is empty, respectively the 
only use case, that came into my mind up to now, 
is that because the CSS approach allows to mix different
types, it needs a fallback behaviour just in case an author
is not clever enough to avoid the situation, that the values,
it has to be interpolated between have not the same structure.
Well, but this is not really a use case, it is just a fallback
for awkward notations of authors.
But if this is considered anyway as awkward notation,
it does not really matter, what the precise effect is, therefore
one still can interpolation affine between the calculated
matrices directly without decomposition. 
If the author does not like it, this is at least a hint to
fix the lists ;o)

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. This means finally, one cannot even compress
longer lists to a matrix so reduce the file size, if the
animation effect matters in detail.

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

Can you list 10 meaningful use cases for the CSS 
decomposition method to interpolate between
two matrices? Can you list use cases for the
animation with mixed transform list values, 
what seems currently the main reason for the
existence of the decomposition method?
Aren't this always situations, where the author
has no precise animation effect in mind anyway?

The decomposition might be ok for the mentioned
Žuse case' 'surprise egg', that the transform lists, 
to be interpolated between, are not the same, 
to get a somehow nice looking effect
for awkward notations of authors. But if the author
intentionally only notes matrices, such an author is
not interested in a somehow nice looking effect
for awkward notations, such an author has done
own numerical calculations and needs only a
simple, fast, stable and predictable interpolation as
mentioned for my use case above.


Olaf

Received on Sunday, 3 June 2012 13:06:35 UTC