Re: [css3-animations] Complex animations

Hi Paul,


> The timing event is not needed imho, as no game is controlling their
> collisions by tracking render updates. We control all game logic in JS,
> everything else will simply become way too slow. We can also cheat pretty
> well, as we have tiles. A character always moves from one tile to the next
> before a collision could happen – so events that trigger after a part or the
> end of the animation work for us.
>

I realize that this is not how a typical game works; it was just an example
how you could do it with minimal js code.
The timing event is still needed though to have smooth animations in your
game. All other event types are asynchronous so by the time it gets to your
callback function, things will have moved so when you update the animation,
you will see stuttering. If your game moves the characters like a chess
board (step-by-step) it might not be needed, but for pac-man style games, it
will be.


>
> Most importantly, we need that API to control complex animations – start
> them, pause them, replace them with a new animation or end them half way. My
> hopes are that something like this could then be easily accelerated by
> browsers.
>

The CSS animation spec already lets you do control starting/pausing by
changing the play state. Replacing or transitioning element can be done by
changing 'visibilty' or 'display' attributes. A problem is the asynchronous
nature of the changes which needs to be addressed. This is why we need to
extend CSS so we can have true keyframes.

Rik


>
> Von: Rik Cabanier <cabanier@gmail.com>
> Datum: Tue, 29 Mar 2011 10:30:03 -0700
> An: Paul Bakaus <pbakaus@zynga.com>
> Cc: Simon Fraser <simon.fraser@apple.com>, Dean Jackson <dino@apple.com>,
> "public-fx@w3.org" <public-fx@w3.org>, www-style list <www-style@w3.org>
>
> Betreff: Re: [css3-animations] Complex animations
>
> Hi Paul,
>
> if we come up with a CSS spec that lets you declare a complex animation,
> you would be able to construct it through JS as well.
> This would allow you to calculate the movement of your character in
> advance. This movement would consist of a time list of various graphics that
> each have a animation with a transform.
>
> The second part of your problem is a little different. In order to do that,
> you need to have a precise timing event so you can determine if your
> character is colliding with something else.
> Mozilla's proposal could be part of the solution:
> http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/
> This proposal lets you call a JS function at precise intervals much like
> Flash's onEnterFrame function. If you combine this with my request to pause
> all animations on the page, you would know the precise state of everything
> in the DOM.
> To detect a 'hit', you could simply look at the matrix and the bounding box
> of each character and see if they intersect with another charactor. If they
> do, you know you need to do something.
>
> Rik
>
> On Tue, Mar 29, 2011 at 12:49 AM, Paul Bakaus <pbakaus@zynga.com> wrote:
>
>> I think 'wrong' is a bit bold :) It really depends on your use case, but
>> I'd be happy for any working solution. So far, we are mainly talking about
>> declarative batched animations. How about taking something actual from the
>> game world: Pathfinding.
>>
>> Imagine a character that walks across several isometric tiles. In CSS, I'd
>> create 8 different keyframe animations that translate from one tile to the
>> next tile, all in a different angle. As soon as  the pathfinding algorithm
>> has been run, I want to batch several animations so the character walks from
>> his origin to the final tile. This is what we've been talking about so far.
>> Now it gets interesting: Modern games usually use a sort of adaptive
>> pathfinding algorithm: If the character hits a solid target within its path
>> that wasn't there before, the path is recalculated, so you really never know
>> what the next animation looks like.
>>
>> How would you solve this?
>>
>> Thanks,
>> Paul
>>
>> Von: Simon Fraser <simon.fraser@apple.com>
>> Datum: Mon, 28 Mar 2011 11:13:57 -0700
>>
>> An: Rik Cabanier <cabanier@gmail.com>
>> Cc: Dean Jackson <dino@apple.com>, Paul Bakaus <pbakaus@zynga.com>, "
>> public-fx@w3.org" <public-fx@w3.org>, www-style list <www-style@w3.org>
>> Betreff: Re: [css3-animations] Complex animations
>>
>> 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
>>>
>>>
>>>
>>
>>
>