What is expected when css transition animation re-triggerd before the last one finished?

[kany...@gmail.com]

I have a question regarding css (transition) animation spec. 

The simple code looks like:

####css####

div {
    transition-property: transform;
    transition-duration: 2s;
}

####js####

//init

div.style.trasform = translate3d(0,0,0);

// at some point, the y offset of transform is changed to 100

div.style.trasform = translate3d(0,100,0);

// 1 sec after, change again

div.style.trasform = translate3d(0,1000,0);

Question:

What should be expected on screen? 

           Timeline 0 ------> 1 -----> 2 -------> 3 second

A:         Postion: 0 ------> 50 ---------------> 1000

B:         Position 0 ------> 50, jump to 0 ----> 1000

Or others?

-kangyuan

[PhistucK]

Have you consulted the draft specification?

https://drafts.csswg.org/css-transitions/, I believe.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Douglas Stockwell]

(A) would be expected. Are you seeing different behavior between browsers? Do you have an example or bug report?

- Doug

[kany...@gmail.com]

Thanks. I guess this section https://drafts.csswg.org/css-transitions/#application answer my question. And i guess it should be A) to my question.

[kany...@gmail.com]

I guess it should be A). 

I found the page https://h5.m.taobao.com/paimai/v3/category.html has the transition issue. You can have a try on Android chrome. When user want to scroll the list on the page, JS change the transform property and trigger transition animation. But the animation is  not smooth, looks like B) effect on screen. And I have simple debug into the chromium, there are multiple transition animations triggered continuously with just one slow fling-gesture and has the sequence of: Transtion1 start -> abort -> Transtion2 start -> abort -> ... Each transition begin from the same Y offset in css transform, which echos what I saw on screen.

I tried safri on iPhone and get the same result. But I tried a Android native browser which is installed on 4.2 Android (not blink backed), not has such issue.

I will file the bug when i am sure it is the browser issue instead of the issue of page scripting.

-kangyuan

[kany...@gmail.com]

I am almost sure there is a bug in chromium. To trigger the bug we need a small transtion-duration. and to re-trigger the transition before last one finished.

For example

div {
    transition-property: transform;
    transition-duration: 0.2s;
}

###

offsetY = 0;

setInterval( function() {

   div.style.transform = translate(0, offsetY, 0);

   offsetY = offsetY - 30;

  }

), 50);

We will observe B) on screen.

I think blink want to solve the issue here. It want to calculate the current computed css value by last transition animation and use it as the beginning state of next transition. However, for the compositor animation which performs on impl thread, the *inheritedTime*  is inaccurately calculated, which can result the animation always jump back to the initial state. For the page, the inheritedTime is easily to be zero. The blink thread regard the animation didn't begin to run yet, but it can actually run on impl thread till next (cc) tree activation. 

I guess we add a animation "merge" operation during tree activation? It is going to find the animations which have same property and live on pending and active tree each. Let the new (pending) one inherit from the old (active) one's animate-able value.

-kangyuan

[Douglas Stockwell]

Please file a bug with a test case at http://crbug.com/new

- Doug

[K.Y S]

Ok, I will be on vacation next few days. Will fire bug early next week.