Re: [css3-animations] Complex animations

One though we have to get around this particular issue is to add a property such as

animation-trigger: [some way to reference an animation on an element]

that would set the start time of an animation to the end of the referenced animation. SMIL supports this nicely, even with simple expressions, but has the advantage that animations apply over the entire document (not just when particular style rules apply). SMIL also handles synchronisation of animations explicitly.

An issue we (Apple) have noticed over the years implementing animation is that in many cases the author would prefer not to have the animation jump past its first few frames. Unfortunately, the start of an animation may require a re-layout which means that the pause may be significant and cause obvious stutters.

Dean


On 28/03/2011, at 7:03 PM, Paul Bakaus wrote:

> (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>
> Datum: Sat, 26 Mar 2011 11:42:24 -0700
> An: www-style list <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