Re: [css3-animations] Complex animations

I agree.
It would be great if that 'API' was declared in CSS. :-)

I think declaring the whole animation would be best, not just a single one.
What if you queue the next one, but because of slowdowns, the next one is
already expired? It's better for the browser to manage such things.

Rik

On Mon, Mar 28, 2011 at 11:13 AM, Simon Fraser <simon.fraser@apple.com>wrote:

> I think the approach of trying to set up the next animation from JS at the
> end of a previous animation is wrong. The browser will never be able to
> seamlessly stitch the two animations together in that case, since the events
> are necessarily asynchronous (to avoid re-entrancy issues). This is
> especially true when the browser is actually running the animations off in
> another thread, as Safari does with some animations.
>
> A better approach would be to design an API for controlling animations. The
> author could then use this to queue the next animation before the end of the
> previous one.
>
> Simon
>
>
> On Mar 28, 2011, at 11:04 AM, Rik Cabanier wrote:
>
> Hi Dean,
>
> I think skipping frames if an animation runs too slow, is perfectly
> acceptable. How else would you keep animations in sync? Flash, video players
> (and probably SVG) do this to keep animations in sync with sound.
> The current animation spec only lets you animate 1 element, so if there are
> multiple elements, you just have to hope that the browser will keep them
> synchronized.
>
> Your proposal for an animation trigger could work, but why not extend the
> keyframes syntax so you can manipulate multiple elements at once?
> My previous proposal would keep the existing keyframes structure and
> extends it to switch direct children on and off at set times. There's
> probably no need to allow deeper DOM manipulation past the first level.
> In this proposal, sub-animations might still not line up perfectly but that
> is usually not that big of an issue.For instance if you have an animation of
> a police car chasing another car, you care about the position of the 2 cars,
> not that the police car's flashing light is lined up correctly. (If a
> designer were to care, he can put everything in the same level.)
>
> I realize that this is not that easy to implement which is why I proposed
> to have a way to just stop all animations if an animation event triggers.
> Reading https://bugs.webkit.org/show_bug.cgi?id=43023 it seems that WebKit
> would still not work correctly. Maybe we would also need to way to 'force' a
> synchronous re-layout from an event handler.
> The flow would be:
> 1. animation ends
> 2. animation-end event triggers and pauses all animations
> 3. animation event handler is processed. This event handler somehow
> requests a re-layout
> 4. when event handler returns, browser will execute a layout
> 5. all animations resume
>
> Rik
>
> On Mon, Mar 28, 2011 at 9:24 AM, Dean Jackson <dino@apple.com> wrote:
>
>> 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
>>
>>
>>
>
>