W3C home > Mailing lists > Public > www-style@w3.org > May 2013

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

From: Alan Gresley <alan@css-class.com>
Date: Tue, 07 May 2013 16:54:40 +1000
Message-ID: <5188A530.5060405@css-class.com>
To: Dirk Schulze <dschulze@adobe.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On 7/05/2013 3:01 PM, Dirk Schulze wrote:
>
> 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

Just testing with current Chrome (Version 26.0.1410.64 m). When I first 
test, Chrome does the short path and when you view another window (e.g 
another browsers) and then return to the test case in Chrome (may have 
to do this a few times), all of a sudden the animation has changed to 
long path. This is using the below code and the bug can be reproduced 
again and again. Once you refresh to browser, Chrome does the short path 
again until the bug surfaces again.

Alan


<!DOCTYPE html>
<style>

@keyframes rotate {
  from { transform: rotate3D(0,0,1,180deg); }
  to { transform: rotate3D(0,.3,1,200deg); }
}

div {
   width: 100px;
   height: 100px;
   background: yellowgreen;
   animation: rotate 1s infinite alternate linear;
}
</style>

<div></div>



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/
Received on Tuesday, 7 May 2013 06:55:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 May 2013 06:55:16 UTC