Re: [css-transitions] Some matrix-based rotation interpolations are "wrong"

On May 6, 2013, at 5:31 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, May 6, 2013 at 5:24 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Can you elaborate a bit more what you mean with switching to this behavior in Blink? As far as I see it in the source code, Blink and WebKit never did it differently then that. Your example works the same in Chrome as in Safari. I am happy to do the changes to the spec and I agree that they make sense. However, this won't have any affect on the bug mentioned by Rik [1]. We will still need further changes. The editors of Transforms are still trying to figure out what happens in Safari for that.
> 
> Please read my email more closely - both Chrome and Safari have the
> "short path" behavior on the example as written, but as soon as you
> change it so that it uses a slightly different rotation axis, or uses
> the matrix3D function either explicitly or via decomposition, Chrome
> currently does "long path", while Safari still does "short path".
> 
> For example, change the rotation axis in the "to" state to "0, .1, 1",
> or add a "translate(1px)" to one of the states, or something else that
> forces us into matrix-interpolation rather than argument
> interpolation.

I see, I was indeed just using the example you pasted. However, I am still puzzled with your solution because of the above named reason. Nothing changes with your suggested pseudo code adaptions in WebKit/Blink. I even build with the max() function (which is done later in the code anyway) and it didn't change anything for me. An animation from rotate3D(0,0,1,170deg) to rotate3D(0,0.1,1,190deg) still takes the long way on the WebKit/Blink decomposition code.

In a later mail you said that you didn't test the change on your own. Did someone investigate on the Blink side? Maybe this contributor can give a bit more information on the changes done.

Greetings,
Dirk

Received on Tuesday, 7 May 2013 05:01:33 UTC