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

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


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

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.


> 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. How could it? It doesn't require any particular frame rate,  
so you never know exactly what will be rendered at any time.

But whatever, we're not breaking that.

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

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

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

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

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?

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


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

> 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

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

Received on Friday, 27 March 2009 20:11:21 UTC