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

Dirk Schulze:

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

This applies as well for scale(0,0), scale(0,y), scale(x,0) etc, 
therefore no really new problem.
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. As long as this is not stabilised by avoiding inversions,
such problems will remain - mainly with the funny effect of 
surprising discontinuities in animations for authors 
(maybe CSS using authors can work around this in some cases 
with a 'rotation' with infinitesimal radius and size around the '0', 
as long as nothing better is implemented/available, but this
requires more manual computation of the timing (keytimes)
by the author ;o) 

> and a undefined matrix for 
> 'perspective'. 

With the few tests (CSS+XHTML) I made related to perspective with 
viewers available for me, I could not see an effect anyway, this was
even worse than for other 3D effects. 

But obviously looking at the matrix in 21 it represents, 0 would be
indeed interesting ;o)

On the other hand - currently it is not yet defined, how to apply
such matrices at all to get a perspective view - maybe it is
an approach to change this matrix and use a respectively 
modified formula ;o) 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.

Due to the graphs in 6.1. d="0" means, that the eye of
the observer sticks into the canvas/object or vice versa - 
one cannot expect a meaningful behaviour for this. 
Because for the perspective property with similar meaning 
it is already mentioned, that the length must be positive,
one just has to define what to do for a not positive
value - automatically one gets the correct behaviour,
if this appears in an animation, including the result of 
a by-animation of perspective - I think, it will apply for
the property and the transform type.

> The interpolation chapter for matrices does not allow 
> interpolation with non-invertible matrices [2]. 

Well, this is not nice. I think, Opera has implemented this for
years already for matrix and I did some simulations with an 
animation of xlink:href of a use element with about 20 references
a second, and of course, there is no visual problem at 0 - it happens
only, what can be expected - everything is reduced to an (invisible) dot.
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.

And I think, to apply this CSS specific decompostion method
to a SMIL animation with animateTransform, one needs to
specify another calcMode anyway. Maybe one should add
a new calcMode 'complex' to get this effect - if needed at all
for animateTransform.
For the currently available methods one simply has to interpolate 
between the list values without a need for inversions or 
decompositions and problems resulting from this - 
especially for matrix this it pretty useful, to get stable and
predictable effects for numerical calculated approximations
of transform effects. Presumable with only the CSS specific
and instable decomposition method it is better for this use
case to continue to simulate the effect with an 
animation of xlink:href of a use element with about 20 
references a second.

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

This is another indication, that such a decomposition approach would be
instable, not suited to daily/serious use and not useful/meaningful for 
(additive) animateTransform at all.


Olaf

Received on Saturday, 2 June 2012 18:03:16 UTC