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

I'm afraid I disagree. Our main goal is to make the most common case  
both simple to author and look good. The way we have specified  
transform animations meets this (I believe).

A secondary goal is to give authors complete control. The current  
specification also meets this. An author can avoid decomposition if  
they want to (it requires more work, but if they are *that* determined  
to control every aspect of their animation then they probably have it  
all worked out already).

I do not believe there are any extra "error" cases. It's nothing more  
than the very simple and obvious animations from scale(1) to  
scale(-1), or skew(89) to skew(91).

Lastly, we chose this approach after authoring a lot of content. It's  
currently implemented in WebKit nightlies if you want to try it out.

Dean


On 26/03/2009, at 10:02 PM, Dr. Olaf Hoffmann wrote:

>> On 26/03/2009, at 6:45 AM, Dean Jackson wrote:
>>> Olaf,
>>>
>>> On 26/03/2009, at 12:49 AM, Dr. Olaf Hoffmann wrote:
>>>> I think, it is not a good idea, that a matrix is decomposed in an
>>>> (arbitrary)
>>>> set of other transformations for animation purposes, because:
>>
>> [snip your points]
>>
>>>> To resume, I suggest to skip the decomposition idea completely.  
>>>> This
>>>> avoids mathematical problems and paternalism of authors.
>>>
>>> We strongly disagree. We came to this approach for a few reasons:
>>
>> [snip my reply]
>>
>> If you wanted more proof here's an example from the apple engineer  
>> who
>> implemented the decomposition:
>>
>> 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)? You'd see a box rotate and shrink, then
>> continue rotating and grow again. This would be even worse animating
>> from 0 to 180 degrees, where the box would shrink to nothing at the
>> 50% mark.
>>
>> Dean
>
> I think, the main points are, that it can cause mathematical problems
> and that there are applications for the matrix animation without
> decomposition as well, currently not accessible at all. Authors should
> at least have the choice, what happens and of course the mathematical
> problems with the possibly missing inverse have to be avoided
> somehow within the decomposition approach.
> In general I do not dislike the idea of decomposition as an additional
> feature to the simple interpolation between two matrices, then authors
> have even more the choice, what they really want. However in case
> this is not possible, authors have already the possibility to  
> provide a
> complete set of transformations, then they should have the possibility
> too to interpolate between matrices.
>
> I think, no author will compute from a set of transformations a  
> matrix,
> write it down and expect, that the original set is reconstructed by  
> the
> viewer for the animation - and the suggested method will not manage
> this anyway. If the author writes down this set, this is transparent  
> and
> understandable for him/her and this is, what will happen in most
> cases anyway.
> Error management for illformed combinations is another problem,
> but this is not very interesting for authors, because typically they
> do not want to publish errors intentionally, therefore a visible  
> indication
> for a stupid notation will be much more useful for authors as a
> composition/decomposition mechanism to hide such errors -
> for example no animation at all, if initial and final set do not fit
> together. This will trigger authors to fix errors instead of assuming,
> that everything works.
>
>
> That matrix animation is not possible currently in SVG without some
> complicated tricks is annoying enough. And I tested the animation
> behaviour for the matrix case in SVG and it works as expected -
> at least for me. Simple possible applications are for example
> animated IFS (iterated function systems).
> And I think, there will be no surprises for 3D (4x4 matrices) as well
> for such application - but of course it looks quite different than  
> such
> a decompostion, that is the reason, why it is a quite different
> interesting feature.
>
> In the example above you automatically think about rotation - why?
> There is nothing incorrect or looking strange if you do not have those
> other transformations or concepts in mind. If you need a rotation, you
> can use rotate etc, not matrix, obviously it is inefficient to  
> simulate a
> rotation with something like a values animation with a lot of  
> matrices.
> In the same way it is inefficient to simulate a matrix animation with
> a huge number of values animations of a set of other transformation,
> what is possible, but not very useful if one can specify a matrix  
> directly.
> If this is decomposed, authors need a large set of explicitly noted
> interpolation values to express, what they really want, resulting in
> something like 10 to 20 values per second animation.
>
> Olaf
>
>

Received on Thursday, 26 March 2009 20:06:31 UTC