>
> I think requestAnimationFrame is tremendously useful (I helped design it)
>> but it can't be a complete solution since when animations are carried out
>> off the HTML5 event loop thread (which you want for smoothness), JS may not
>> be able to run at the moment the animation finishes.
>>
>
> This is why being able to pause all animations is important.
> I don't think that this will give many issues with smoothness as long as
> you use animations for the bulk of the motion and keep you JavaScript to a
> minimum.
> The Flash player pauses all rendering during its ActionScript phase and
> real world performance of games and animations is fine.
>
>
> WebKit on Safari and iPhone renders some animations on another thread, at
> display-refresh frequency (60fps). Dropped frames are very noticeable with
> such animations. Pausing animations while JS is running is simply not an
> option for us.
>
I'm not suggesting to change the default behavior or pause animations when
any JS runs. You could provide an option to do the pause when you register
an animation event handler so it only happens if you want it to.
When changing animations through JS, there has be a way to freeze the state
of your animation at the c++ level. If not, you can't keep all the separate
animations synchronized and you're better off animating everything through
JavaScript.
As mentioned before, having a declarative syntax for true keyframes is the
best solution. It will also significantly lower the need and complexity of
animation event handlers
Rik