- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Mon, 4 Jun 2012 19:06:17 +0200
- To: public-fx@w3.org, www-svg@w3.org
Dirk Schulze:
...
> >
> > [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':
Often it is a good idea not to use the same srcew for more than
one function ;o)
A more complex approach as the CSS composition may
require a more complex solution - as we can see with the
non invertable matrices - no problem at all for animateTransform,
one of the core problems obviously for the decomposition method.
Because it does not appear for animateTransform, this should
be of no importance for animateTransform.
And once one manages to avoid inversions, the problem
vanishes as well for the CSS approach.
>
> <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).
<animate attributeName="transform"
by="matrix(1 0 0 1 0 0)" dur="5s" fill="freeze"/>
could work in the same way as
<animate attributeName="transform"
by="scale(1)" dur="5s" fill="freeze"/>
the problem is only introduced by the surprising idea,
to apply the decomposition as well, if there are only matrices.
This does not mean, that I think, that both is of any use
for authors, but at least, there is no additional problem,
cumulative behaviour works as well.
> Because of the reasons I mentioned before: The
> numerical interpolation of each value in the list of matrix, seldom
> produces reasonable _visual_ results.
In my simulations as well as for the all the tests with Opera 9.5 to 11.0
(they all use simple affine interpolation) always the results are
reasonable visual results. They are always predictable and
it is easy to estimate, how many values list items are required
to approximate an intended effect.
Therefore my observation is, that affine interpolation of matrices
provide always reasonable visual results.
If other got other results, their simulations have bugs, respectively
the viewers have rendering problems/bugs not related to this ;o)
> I know of one of the developers from
> Batik that they got the same experience on one of their own tests.
I never checked, whether Batik/Squiggle ignores the fact as well,
that the matrix type is currently not animatable in SVG 1.1 and SVG tiny 1.2.
> Therefore: CSS Transforms allows the same kind of animations like you can
> receive with 'animateTransform'.
There was a decision already to allow the matrix type for animateTransform
for SVG 2 as a progress
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#animateTransform_type_matrix
>
> We are talking about the behavior beyond 'animateTransform'.
Well, definition/clarification of behaviour of 'animateTransform' isn't even
finished. This has to be done as well, because the amimateTransform
approach is often used and known already to be widely accepted and
working in the broad range of already defined situations.
There is not much to do to finish this finally.
>
> > 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.
If I want to interpolate affine between -1 and 1 and the defined
method creates a problem at 0, this indicates anyway, that the
method has a problem and not the 0 ;o)
If you know exactly, what you want, it is often quite easy to find the source
of the problem ;o)
>
> > 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!
The matrices are the same, but it is a difference if you do an interpolation
of a from -720 to 720 in rotate(a), converting this into a matrix or
to interpolate between the related matrices. Therefore you will animate
the a in rotate(a), if you need a rotation.
But if you do not have such an specific function to describe the animation
intent, you need a longer list of matrices to get an approximation.
This is similar to the approximation of a path (imagine the path d attribute).
Typically it will be not sufficient just to specify the initial and the final
point of your path, you need a longer list of points between to
get a nice visual representation of an arbitrary curve. The equivalent
of rotate would be here a notation in polar coordinates. The related
proposal for SVG 2 was rejected :-(
The simplest approach is to use a list of lines to approximate the curve,
this corresponds here to the option of affine interpolation between matrices.
The refined approach is to use cubic curves (commands C, c, S, s), still
you need a list of such cubic curves to approximate an arbitrary curve.
This is, what you can do with affine interpolation between matrices and
more or less with keySplines, keyTimes.
You need no decomposition of the path for example in fragments available
in polar coordinates, some in hyperbolic coordinate, spherical coordinates
etc. This is, what decomposition does with matrices.
As an author, the best you can do with such a decomposed object is, to
compose it again to a matrix and follow the simple affine approach.
To do the approximation, the author needs the control, what remains
quite simple for lines and cubic curves in the path example, but can
be quite difficult, if the author is only allowed to provide initial and
final point and the viewer provides arbitrary curved interpolation
between those points (what corresponds to the decomposition method)
To approximate the intended path with arbitrary curved segments,
may be a nice play (eye candy, surprise egg, 'Überraschungsei'),
but nothing intended for real serious application.
No author of a serious application will accept
such a fun interpolation without control over the behaviour.
> And still, they are not bidirectional. Using a matrix
> to describe a transform function can lead to a lost of information.
If the matrix contains all information you have, no.
You assume, that you always have a better representation with
another function, as polar coordinates or hyperbolical coordinates in
the path corresponds, but for most paths it turns out, that you
need only a representation in the cartesian coordinate system and you either
provide a longer list of line segments or a slightly shorter list with
cubic curves.
Only for specific curves it is an advantage to use polar coordinates
and for some others hyperbolical coordinates are better,
nevertheless typically it is still simple to do the approximation
for this in cartesian coordinates as well.
> 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.
Of course, this can mean an information loss, but if you already start
with matrices, you do not have such a problem, as long as you do
not try to decompose it.
> I think this is what you
> meant with 'unstable' before.
No, this is an obvious effect, that is always available, if you turn
skewing, rotation etc into a matrix,
rotate(180), rotate(-180) and scale(-1,-1) turn out to be the same.
If you need to animate rotate(180) to rotate(-180) you better use the
type rotate and not matrix ;o)
But if you need to do the animation for something similar, you do
not have a function like rotate or scale for, it is obviously much simpler
with affine interpolation and a longer list of matrices to approximate the
intended effect as to be dependent on the unpredictable decompostion
method, that calculates things, you are not interested in, as in the
path example, it might generate elliptical or hyperbolic arcs instead
of the cubic curves you need including access to control points
(keySplines here, you still have them with the decompostion method,
but due to the decomposition, you do not know anymore, what they mean ;o)
> To avoid these situations, the specification
> defines when a matrix can be decomposed.
The decomposition does not avoid problems, it creates problems.
Especially it frustrates authors of serious applications, who really
need the matrices to get an intended effect.
> For CSS Transforms, the matrix
> must be invertible. This is consistent with all decomposing variants I
> found so far.
If this is the case, the complete decomposition approach is obviously
not a good idea ;o) This would be a simple indication.
...
> >>
> >> 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).
No, it is an intrinsic problem of numerical matrix inversion.
Maybe you need something like maple to do the inversion
analytically without any limited number range or something like
that to avoid artifacts.
Of course, with some tricks one can reduce the effect
by analysing and rearranging the matrix before numerical
inversion, but one cannot completely avoid artifacts from
numerical inversion.
>
> > 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.
Well, if one uses matrices, one does not even want them to be described
by rotate, scaling, translating and shearing, one simply wants to use
matrices, because there is no better representation of the current problem.
If there would have been a better representation using rotate, scaling,
translating and shearing, one would have used these functions ;o)
I did these simulations and tried yesterday something with the Opera
implementation - well it does not flicker more or less than for other
animations - would be a surprise, if it would ;o)
Obviously authors, prefering the approach with 20 discrete values
per second will normally prefer other formats than SVG, some
video format like MPEG, OGG-video etc. And such a decomposition
barrier will guarantee, that they will never take SVG into account to
solve the problems in a more elegant and effective way.
> An author wants a
> smooth animation.
If the authors wants a smooth animation, it should be smooth, indeed.
At least without decomposition it is with affine interpolation between
matrices.
> Just because it is mathematical clear how numerical
> interpolation looks like, does not mean that you get the visual result you
> expect.
Depends on you expectations, don't you think so?
Just why I expect, that I will get a lot of money next week,
nevertheless, maybe this will not happen. This does not
mean, that something with the money is wrong, maybe just
my expectations are wrong. That there can be a problem
with the money as well (debt crisis in USA and several european
countries), can be assumed to be an independent problem ;o)
And as mentioned before, I did not just look on the mathematics,
as experimental physicist of course I do experiments as well -
and as expected from mathematics (much more reliable than
arbitrary expectations by the way), affine interpolation between
matrices is a pretty good and stable approach to approximate
time dependent arbitrary transformations.
> 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.
Would be fun to see some of the examples they used.
Presumably they tried to interpolate between a combination of
the already known functions like rotation, scaling and skewing
represented by matrices and were surprised, that they do not
conserve this structure within the animation - this would simply
indicate, that matrices are difficult to understand, not a problem
with the interpolation, that always works pretty simple and
predictable. If you simulate a fool, you cannot be surprised
to get foolish results ;o)
>
> > ...
> >
> >> 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.
>
No, because mathematics is much more reliable than arbitrary expectations
and suggestive texts, those are the core part of such a draft.
This is the 'secret of success' of natural sciences.
Once you manage to represent it in a formula, it can be considered to
be understandable and even more important - usable and testable.
...
>
> 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.
No surprise, that commercial programs fail so often.
Trials and tribulations are unavoidable. But of course in your
final text/product you only need to provide your conclusions
and successes, not all the steps you failed (and learned form
failures). Nobody needs this history of failures or such a
suboptimal cowpath, finally one needs only the optimal
solution (Occam's razor).
And I think, it is against the whole idea of W3C production
with the option of open discussions and comments
from everybody. If all this has finally no effect or is
one eye candy, one can forget about the whole
W3C idea.
Isn't there already some 'recommendation' for
'microsoft word' around, that can be only implemented
completely from microsoft just for the same reason?
>
> >> 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.
As mentioned above, this 'illegal' but meaningful behaviour can be seen in
Opera versions 9.5 to 11.0, no information, why this is not available for
example in 11.6.
Should not work in 9.2x or earlier versions (did only test 9.23, due
to incompatibilities with my current debian version, earlier versions
of Opera require an older version, I did not start just for this).
>
> > 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.
But with affine interpolation as well, for example feConvolveMatrix has
some quite delicate attributes. Soon the viewer has to decide, if
only discrete animation is possible or linear as well. No surpise, that
some fail in my test suite ...
According to my tests feDisplacementMap seems to be quite
problematic for viewers as well.
And if I have a look on my filter animation test statistics,
best is Opera 11.0 with 99/111, next are the old Adobe plugin with 77/111,
Gecko 12.0 with 55/111, Batik/Squiggle with 1/111.
...
>
> > 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.
well, 750deg was just a typo, but nobody would expect something
like a rotation at all, if only the matrices for this are noted.
Such an expectation only indicates, that the expectators made a wide
curve around the whole concept of a matrix ;o)
> And yes, with matrix interpolation
> you would not see two turns. But it is easy to address both behaviors.
My assumption is, you will not see them with decomposition either,
if you just note the matrices.
To address this with animateTransform is quite simple, just use
the rotate notation including the rotation center (not available
for CSS unfortunately).
But this example was just to show, that inappropriate examples
can result in wrong conclusions. You need a real task or problem,
for example to approximate the behaviour of an arbitrary time
dependent matrix M(t) applied to an asymmetrical object like the text
'some text'. My assumption is, you will have a lot of fun with the
decomposition approach, but you will get acceptable results with
a simple affine interpolation within minutes just by guessing the
number of matrices you need.
...
>
> > Therefore the 'core use case' for authors seems to be
> > to avoid, that the decompostion ever takes place ;o)
>
> For sure not.
But you did not provide a single use case for anything different ;o)
>
> > 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!
This is what I noted already as fallback behaviour for awkward author
notation.
This is not really an application, this is only necessary to define somehow
for the function lists, not for interpolation between matrices.
To resume, effectively you have no (other) use case for the decompostion.
I provided at least one relevant for the affine interpolation between
matrices.
Therefore I think, the assumption looks wrong, that the decomposition covers
more than 90% of use cases for matrix interpolation, if provides mainly
eye candy for awkward author notation for the transform function list variant
and no use case, but only frustration for the interpolation between matrices.
Olaf
Received on Monday, 4 June 2012 17:15:27 UTC