Re: [css3-animations] Complex animations

(Adding public-fx)

Hi Rik,

I had similar trouble. The biggest issue I discovered was the need to start a new drawing/js/browser cycle, meaning that after the animationend, you can't just restart or continue animating – you have to force the browser to end its current painting cycle first, using setTimeout(fn, 0) (at least, that's how it is in WebKit). This makes everything bumpy and ugly if you have continuous animations after each other.

As I consider this clearly a bug, I've added a ticket in the WebKit bug tracker some time ago: https://bugs.webkit.org/show_bug.cgi?id=43023

It would be lovely if you could add yourself to this one to raise attention, and maybe even add an isolated test case to it (I'm just linking to Apple's own dev resources, which didn't seem enough).

Thanks,
Paul

Von: Rik Cabanier <cabanier@gmail.com<mailto:cabanier@gmail.com>>
Datum: Sat, 26 Mar 2011 11:42:24 -0700
An: www-style list <www-style@w3.org<mailto:www-style@w3.org>>
Betreff: [css3-animations] Complex animations

All,

the asynchronous nature of CSS animations makes it hard to keep different timelines in sync.
I posted an exampe of this(webkit only): http://mobiletest.host.adobe.com/w3c/Metro.html
After the animation loads, you will see that the dog's head is not lining up with his body. Depending on the speed of your machine, the animation will also break off before it run to its end.

The reason is that the event that signals the end of an animation is handled asynchronously.
The flow is:
- animation ends
- an 'animationend' event is sent to the js code
- the js code starts up the next animation
During this time the other animations keep running so they are no longer in sync.
The event handling also adds to the total time of the movie so sometimes the movie will restart before its children have run to completion.

the Mozilla folks are aware of such issues and have a prototype to work around this:
http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/
I think it's a step in the right direction but not a complete solution.
To work around this problem in the short term, it would be nice if we can declare animation event handlers so that when they trigger, ALL animations on the page are paused until the event is handled. After the event is handled, all page animations will resume.

The ideal solution would be to extend the keyframes structure so that you can describe complex animations.
If you can declare that children can become active or disabled at certain points of the animation, there would be no need to rely on JavaScript.
This approach would have the additional advantage that the browser could 'skip' frames if it detects that the animation is falling behind.
The idea would look something like:
@keyframes sample
from{
:nth-child(1): {display: block;}
}
50%{
:nth-child(1): {display: none;}
:nth-child(2): {display: block;}
}
to{
:nth-child(2): {display: none;}
}

Rik