Re: [css3-2d-transforms] matrix animation

Dean Jackson:
> On 28/03/2009, at 6:23 AM, Dr. Olaf Hoffmann wrote:
> > Chris Marrin:
> >
> > ....
> >
> >>> Well, then explain a simple approach for authors to specify an
> >>> animation (direct interpolation) between matrix A and matrix B
> >>> with an accuracy better than one device pixel.
> >>> If you can do it with the current draft, then I'm almost convinced,
> >>> that at least nothing is missing, even if other things are available
> >>> twice.
> >>
> >> I'm not sure what you mean by "better than one device pixel".
> >
> > That is a requirement for example for SVGT1.2 and SVGT1.1, one can
> > simply test (and for several tests WebKit is already better with this
> > as for example Opera ;o)
>
> I have no idea what point you're trying to make here. There is nothing
> in the CSS proposal that would break accuracy in this way.
>

If you meet this requirement, there is typically no visible difference 
between an approximation/improvisation and the really intended
behaviour. If the differences are larger, obviously the approximation
is not good enough and has to be improved. 
I cannot see the problem to understand this, if something has to
be checked, this happens always within some allowed error margin
and some statistical assumption of what is good enough and what 
not, this does not depend on feelings, but on measurable entities
like this device pixel.



> >> If you
> >> have a matrix with just translation values, for instance, then matrix
> >> animation would animate from one to the other just as accurately as
> >> animating the components directly.
> >
> > No. It is noted:
> >
> > "If the ‘from’ and ‘to’ transforms are both single functions of the
> > same type:
> > ....
> > For matrix:
> > the matrix is decomposed using the method described by unmatrix into
> > separate
> > translation, scale, rotation and skew matrices, then each decomposed
> > matrix
> > is interpolated numerically, and finally combined in order to
> > produce a
> > resulting 3x2 matrix.
> > "
> > That is in general not the same a to interpolate between the
> > components of
> > the matrix.
>
> Chris Marrin's example was "matrix with just translation values". When
> you decompose that using the method we describe and animate, things
> will work fine.
>

I cannot see, how your comment is related to the discussed problem.
Obviously for translation there is never a problem, but this is not
the problem here. With a general matrix animation there are some 
matrices with the same result with and without decomposition. 
But there are others, for which it makes a difference. 
I care more about the general case, where it makes a
difference as for the others.

Maybe Chris Marrin draw the wrong conclusion from a too
simple example he has choosen. There is no need to follow
him, drawing wrong conclusions too.

> > If I want to do exactly this, the decomposition causes a lot of
> > trouble,
> > because one has to work around it with a lot of values within the
> > animation
> > and one has to calculate carefully,
>
> As I've said before, the goal is to do the right thing for authors in
> the majority of cases and to allow them full control if they are like
> you. There is nothing stopping you from decomposing your matrix in
> advance, anyway you like.
>

The opposite is the case, if only decomposition is available for the
matrix type, I have to work around this decomposition to get the
intended effect to interpolate between two matrices. I do not
want do decompose them myself, I simply want an animation 
interpolation between them.
To do this, instead of noting for example the two matrices, I'd
like to have the interpolation between, I have to provide about
10-20 matrices per second to get approximately the same
effect with decomposition as without. And I still have to check,
if the approxmation is proper enough. This is a lot of 
unnecessary work just due to the decomposition problem,
I'm not even interested in, in this case.



> We're telling you we came up with this approach and documented it
> because it is what we found to be best. You might not agree, but you
> also have not actually tried it, nor given us any examples that are
> impossible/broken with our current approach.
>

As I already wrote, I tried it, therefore it is not helpful for the discussion
to claim, that I did not try it, because I know best, what I tried and what
not. What I tried is the interpolation between two matrices A, B
with the current Matrix C, time t from 0 to 1:

(*) C(t) = Bt + (1-t)A

And you noted already an example on your own, which makes a
difference:

"Imagine animating from [0.707 -0.707 0.707 0.707 0 0] to [0.707 0.707  
-0.707 0.707 0 0], which is an animation from 45 degrees to -45  
degrees. Without decomposition at 50% you have [0.707 0 0 0.707 0 0],  
which is a rotation of 0 degrees (this is correct) but with a scale of  
0.707 (definitely incorrect)?"

Due to the formula above what you noted to be incorrect is correct 
and what I need.
To fix this with an implementation of decomposition I have to provide
a large list of matrices for the animation, that the effect of decomposition
becomes neglectible.

Because you claimed, that authors can specify what the need/want,
I just asked for a simple method to derive this large list to get an
approximation within the error margin of one device pixel.

Chris Marrin claimed in his mail the formula (*) will be applicable
for animation of a matrix only case, what would be fine.
Obviously for too simple examples there is no difference between
with and without decomposition, what does not help for non
trivial examples.
Therefore I had to point out, that this is not true according to the
prose of the current draft for a general matrix animation.



> > how small the steps have to be to
> > meet the 'device pixel' condition.
>
> Note that SVG does not say you need device pixel accuracy during an
> animation. 

It was only my requirement for the list of matrices to approximate
the behaviour without decomposition with a viewer, which performs
the decomposition, in case I need the animation without.
Some authors may have lower requirements to the qualtity of
approximation, some higher. The choosen value is not very important,
the method to meet the requirement for the author with his 
computation/workaround is interesting.
If you claim that it is no problem for the author to specify the
intended animation with the current set of possibilities, we have
to note an error margin, which is no problem for me as an 
author to prove your claim.
Up to know, you did not offer such a method, therefore my
assumption still applies, that it is not trivial to create such
a list, for example for the task mentioned above. Maybe I'm
wrong with this. You simply can show me the list together
with the method, than we can check it somehow and then 
we will know, that it is (not) trivial for you to solve the task.
In the best case, I learn something. In the worst case, we
learn both, that it is not trivial for us to provide such a list
for an approximation with the noted requirement.
Maybe someone else knows it better.
If not, it seems to be a good idea to provide a method
to interpolate between two matrices without decomposition,
either instead of decomposition or additionally.

Off topic:
[
SVG does not claim something different for animation, it is noted, 
that the display has this accuracy. If I manage to show somehow, 
that the difference is  larger, than the viewer does not meet this
requirement.

> How could it? It doesn't require any particular frame rate, 
> so you never know exactly what will be rendered at any time.

Because it is only about what is displayed, you just have to 
check it for each frame, not for any time. However because
in SMIL animation it is possible to end an animation at 
any time, it is no big problem to check that at least frozen
values are correct in the next displayed frame.
And SVG does not mention at all, that frame have to be
used, some future devices may be able to create it really
continuous as intended by the author.

But this is not much related to this much simpler CSS animations.
It does not even have some information about accuracy, therefore
my assumption is, that if I manage somehow to show visible 
deviations, than a viewer has already failed.
]

>
> But whatever, we're not breaking that.
>

I do not claim, that you are breaking something, because you
did not even start to provide a method or list related to the
task. It is no implementation but a simple sample showing 
that it is simple for an author to note, what is intended in a
specific case - in this case an animation interpolation (*) 
between two matrices.

> >> Same for scale and rotation. It's
> >> when you combine everything that things get interesting. And in that
> >> case, we believe the author's intent is to go from one "pose" to
> >> another in the most natural way. For instance, if one pose is the
> >> object at a scale of 0.5 with a slight cant up and to the left and
> >> the
> >> other pose is the object at a scale of 1 with a slight cant up and to
> >> the right, then we believe the author's intent is to smoothly scale
> >> up
> >> the object while at the same time pivoting from left to right. And
> >> that's what you would get with matrix animation. For instance:
> >>
> >>     from: -webkit-transform: scale(0.5) rotateX(15deg)
> >> rotateY(-30deg);
> >>
> >>     to:     -webkit-transform: rotateX(15deg) rotateY(30deg);
> >
> > I count this as 'stupid notation', if an author does it - ok and we
> > all know, that authors will do this, if there is an effect.
>
> It's not stupid notation. It's easy for you to assume it is stupid if
> you're only thinking of two states, but imagine a case where you are
> transitioning between thousands of states (a pretty common thing if
> you consider the complexity of a modern UI). It is not always
> practical to author each state with the same list of functions.
>

Yes, maybe, it saves some space if the missing transformations
are added automatically. However with decomposition the result
gets opaque for the author. Just for clarity and to be sure, that
really happens, what is intended, most authors will note the
complete set just to be sure, that the decomposition does not
create something different than intended. 


> I would consider this way more common and useful that people who
> reduce everything to matrices up front (which is the only case you
> seem to be concerned with). 

No, because most people are not familiar with matrices, they will
not use them at all and prefer to specify a list of other transformations
to get the desired effect, because it is simpler to identify the effect
of rotation, translation, scaling and skewing separately.
Only those people will calculate and use matrices for an intended
effect, who know to work with it. I do it, but if I need a rotation
followed by a skewX, a translation, a rotation, a skewY, a scale,
a rotation, translation, skewX again, rotation, etc, I certainly will 
note exactly this long list instead of computing the matrix, because 
the matrix animation will typically result in something different 
(with and without decomposition for the matrix). Therefore I would 
only note a matrix, if I know what I do and if I need an interpolation 
between two matrices - for whatever reason.



> For one, that means they are probably 
> using a tool of some kind.
>
> > But such funny cases are not in the center of my interest, because
> > it is simple for authors to provide two sets fitting together to avoid
> > such a problem.
>
> It isn't always simple.
>
> > Whether this is tried to fix somehow or whether
> > nothing happens to indicate that the author should note unambiguously,
> > what was intended, is a matter of taste...
>
> Again, we want good taste in the most common cases. We are giving you
> the option to eat something really awful if you want to.
>

Currently not, this is the main issue of this discussion.
I cannot do, what I need, because the matrix is noted to be
decomposed for animation.


> >> This can't do a component by component animation because the
> >> functions
> >> don't match. But a decomposed matrix animation would give you the
> >> desired result.
> >
> > If the matrix animation is left to animate between the components,
> > this can be simply used to trigger the decomposition:
> >
> > from: -webkit-transform: scale(1) matrix(...);
> > to:     -webkit-transform: matrix(...);
> >
> > then results in a decomposition and this one not:
> >
> > from: -webkit-transform: matrix(...);
> > to:     -webkit-transform: matrix(...);
>
> To repeat myself again, we want to do the right thing for the majority
> of authors. If you don't like the decomposition you have the ability
> to make your single matrix into a list of matrices.

This contradicts with your claim above to allow authors to
shot theirselves in their foot if the would like to ;o)
I agree, that most authors would not like to do this, but to
exclude this excludes intended use cases as well.
What is awful or not, is sometimes a matter of taste, what
can be quite different for different people, therefore it 
should be not the target of the draft to teach authors 
good taste in the sense of the draft authors. It should
allow authors to do what they currently need in a simple
way, if possible.

>
> >> And linear interpolation of the matrix values would
> >> give add a implicit converse scale that would interfere visibly with
> >> the smoothness of the scale from 0.5 to 1.
> >>
> >> Do you have any practical use cases where a linear interpolation
> >> would
> >> do something reasonable (much less preferable) where a decomposed
> >> matrix would not?
> >
> > I think, I already noted IFS (iterated functions systems, done with a
> > cascade of nested use elements in SVG for example), they are often
> > used with a matrix as generator and can create something like
> > tree structures or leafs, fractal structures - to animate those
> > matrices can result in quite interesting effects (assuming that the
> > processor is fast enough to compute this, well we have CUDA-GPUs
> > today with more than a Tera-FLOP, but if the author is careful,
> > with a simple sample this works pretty good already with an
> > ordinary 10Giga-FLOP processor).
> > But if you have both an IFS with recursive used use elements
> > and you have to work around the decomposition of a matrix
> > doing a lot of number crunching again to get a proper animation
> > with a lot of values, this will get soon to much and the simplicity
> > of notation for IFS is lost again.
>
> But you only have to do the number crunching at author time. And if
> you wanted simplicity you would use the component functions like
> rotate rather than matrix.

No, IFS are often pretty simple for the author, most of them can be 
simply hand coded. This is the advantage of vector graphics.
And if both is available, lists of 'simple' transformations like rotation,
translation, scaling, skewing and simple matrices, there is no need to
calculate something for authors. 
This happens only, if either the simple transformations like rotation
would not be available or the matrix interpolation is not available,
in both cases authors have to start nasty number crunching to 
realise/approximate the not available variant with the
available variants.
For IFS (with SVG, for (X)HTML this is possible too, but not
trivial, because there is nothing like the use element; object or
iframe maybe, but with this there is no control on the depth
or recursion - ugly for the viewer) the files often are only a few 
kilobyte, but the viewer has to crunch for a few seconds to get 
the result.

>
> Anyway, I'm not sure you answered the question. Can you show me why
> the decomposition is not reasonable and, more importantly, unavoidable
> in this case?

Because the author will note the list of rotation, skewing, scaling, 
translation, if this is convenient and results in the intended effect and 
will note a matrix, if this is preferred and results in the intended effect.
For a static image the effect is the same, but not for animation. 
And what the intented effect is, is the problem of the author, not of 
the implementor of the viewer.
If something is not available, the author has only the choice to skip
the idea at all, to use another format or to work around the limitations
with some approximations and tricks, what often implies a lot of 
knowledge, time and computation.
It is possible too, that some authors might prefer to have a 
decomposed variant for their matrix animations, if available.
Then it would be the best for authors of course to note, whether
they need decomposition or not. However, even if not
available, it is simpler to note the explicit decomposed
list resulting in exactly the intended behaviour manually
as in the other case to approximate only the intended effect, 
because it is simply not possible to write it down exactly due to 
limitations of the used format. 

>
> >>> And it does not solve the possible mathematical problem with the
> >>> inverse, just to believe, that it works ;o)
> >>> I had already similar discussions to fix such believes for
> >>> constrained transformations in SVGT1.2.
> >>
> >> A non-invertible matrix would result in nothing rendered, so what
> >> practical use do you have for them? Again practical examples would be
> >> helpful.
> >
> > Ok, an author may want to start or end something as an 0D or 1D object
> > to fade in or out an object - nasty, if it just does not work,
> > because there
> > is a problem with the decomposition, the author does not really need
> > to
> > fade in or out.
>
> Wait. Have you actually tried this? I have, on both a system that
> decomposes (CSS) and one that does not (SVG) and it worked fine (it's
> a miracle!!)
>

As already noted, I use no C, therefore I cannot simply embed
the C-code provided in the draft to simulate the behaviour with
decomposition. Concerning 3d transforms the perspective transform
is missing as matrix/formula, the skew is ambiguous, therefore I
cannot simulate this currently. The animation strategy is quite
different from the SMIL/SVG animateTransform with possible
additive behaviour and postmultiplicative operation, therefore
it will take some time to write scripts simulating this CSS approach
anyway. 
And the code - as far as I understand this - notes only to calculate 
the inverse, nothing about the problem, the inverse might not exist. 
Chris Marrin claimed above, that nothing is rendered.
If WebKit manages this anyway with the intended display within
the progress of animation, this is pretty good, but has to be
noted in the draft in a readable and understandable way 
(not just the C-code), to ensure, that any viewer will manage this. 

I have seen already crashes with nasty SVG transformations,
because obviously 'shit' happens in some implementations, if
those problems are not mentioned at all.




> > Obviously the author can do this with scaling too, not just
> > with matrix, but with matrix this can be simply generalised to get a
> > less simple effect to avoid, that it gets boring to the audience soon.
>
> I'm missing your point by now. See above - it works. We made an
> implementation decision to not make the author's computer explode when
> they generate non-invertable matrices.

Good decision - note, what to do in the draft for other implementations,
because most people do not need exploded computers ;o) 

>
> > In an animation with more than two values an author may want to
> > mirror an object, setting explicitly one value to a lower dimension.
> >
> > Note, that with vector-effect non-scaling-stroke  of SVGT1.2 it is
> > possible to keep such low dimensional objects visible, this can
> > result in other interesting effects with animated objects or animated
> > transformations.
>
> Yes, agreed. And nothing we've done will break this.
>
> At this point I'm beginning to think the conversation is becoming
> useless. Is there anything you can come up with that will be more
> convincing? Remember, here are the requirements:
>
> 1. most common cases work and look best
> 2. other approaches are possible
>

I agree with this, I just want to ensure, that 2. really works,
what currently seems not to be the case for matrix interpolation (*).

I can see two options:
1. no decomposition for the case of a matrix as transformation
2. some property or other notation to switch on and off decomposition
for the matrix case.

The first option is not very convenient for those people, who expect
something of simply appearance from matrix animation, however, 
they have at least the chance to note the list of transformations
(without matrix) to meet their expectations. 
The second option could satisfy those people as well as those, 
who do not need/want a decomposition, because the have other
intentions.



> It would help if you provided real examples, as in a piece of code
> that would be what 99% of people would author and that clearly
> produces an incorrect result in the current system.
>
> Dean

Because I do not know 99% of people, I can only povide samples
and simulations I have, I noted them already. I do not have to
realise everything, what I have in mind, because a lot of those
things I can simply describe and imagine.
However, I think, the 'HTML5' WG learned already, that more than
90% of authors are doing it wrong anyway, from this point of view,
we can assume, that in this range authors do not even know, what
they really want or how to realise it correctly. 
But if everything is removed, what can be dangerous for them,
there is a good chance, that possibilities are removed too, which
could have be used to create some extraordinary and excellent
content too by a small amount of authors, who know what they 
want and do.



SVG sample/freak show (description is available in the desc element):

http://hoffmann.bplaced.net/svgtest/usematrix01.php
http://hoffmann.bplaced.net/svgtest/usematrix02.php

(invalid SVG) sample containing not only the simulation, 
but an animation of the matrix type too, works with current
versions of Opera:
http://hoffmann.bplaced.net/svgtest/usematrix01a.php

IFS article at wikipedia:
http://en.wikipedia.org/wiki/Iterated_function_system
Simple SVG-IFS without animation:
http://hoffmann.bplaced.net/svgueb/fractal1.php
The transformations are done here with translation,
rotation and scaling to simplify explanations in a
tutorial, however as can be seen the in the
wikipedia article, authors use often matrix like
operators too. Both is possible and done.
Generators for known structures are typically
only given in the matrix form. 


Solar system (no matrix, but could be improved by
3d-transforms and perspective projections):
http://hoffmann.bplaced.net/svgtext/solarsystem.php

I think, this still does not work with the current
perspective projections of the draft and not with 
matrices, shows however something like the 
rotate3d for the Platonic solids (note the distortion
of straight lines due to the perspective projection):
http://hoffmann.bplaced.net/svgueb/tetraeder1.php
http://hoffmann.bplaced.net/svgueb/hexaeder1.php
http://hoffmann.bplaced.net/svgueb/oktaeder1.php
http://hoffmann.bplaced.net/svgueb/dodekaeder1.php
http://hoffmann.bplaced.net/svgueb/ikosaeder1.php

Received on Saturday, 28 March 2009 18:32:25 UTC