Bug 43023 - CSS Animations: Restarting animations without a setTimeout doesn't work
: CSS Animations: Restarting animations without a setTimeout doesn't work
Status: VERIFIED REMIND
: WebKit
CSS
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
: http://developer.apple.com/safari/lib...
:
:
:
  Show dependency treegraph
 
Reported: 2010-07-27 01:04 PST by
Modified: 2011-03-29 12:15 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-07-27 01:04:43 PST
Hi,

it seems that this bug is so apparent that Apple's own guidelines have to workaround it, as they're all using setTimeout to restart an animation. This is actually pretty severe, as there's currently no way to animate smoothly from one keyframe based animation to another.

I'm having this specific issue as I'm animating walking characters in an isometric path (in eight directions). So the animation goes into one direction for one tile (say, 45px), and then the animation needs to be restarted due to the nature of the tiling. With setTimeout and plenty of characters, you'll see noticable pauses, as the setTimeout is only executed after the current action queue is done.

If there's already another workaround for this, please let me know and I'll be quiet :)
------- Comment #1 From 2010-08-02 13:26:42 PST -------
This isn't a problem specific to animations. It's a result of the way that browsers batch style changes.

One workaround is to use offsetWidth to force the engine to to do a style resolution/layout.

This bug has no testcase and does not describe a specific issue, so closing.
------- Comment #2 From 2010-08-03 01:16:39 PST -------
Excuse me, how is this not a specific issue? It is such an apparent issue that even Apple is recognizing it. And yes, there is a testcase attached in the URL specified, which is best showing the significance when Apple itself needs workarounds.

Thanks for the information that this is related to style change batching. This doesn't make it any better though. Might need to change a category or open another ticket. If you give me instructions about the right category, I'll go right ahead.
------- Comment #3 From 2011-03-23 04:41:54 PST -------
Bump. This is a real issue.
------- Comment #4 From 2011-03-28 11:21:51 PST -------
I think https://bugs.webkit.org/show_bug.cgi?id=54151 might cover this. We need to flesh out the API a little more, but it would be something like:

var a = myElement.webkitGetAnimation()[0];
a.pause();
a.elapsedTime = 0;
a.play();
------- Comment #5 From 2011-03-29 00:54:23 PST -------
(In reply to comment #4)
> I think https://bugs.webkit.org/show_bug.cgi?id=54151 might cover this. We need to flesh out the API a little more, but it would be something like:
> 
> var a = myElement.webkitGetAnimation()[0];
> a.pause();
> a.elapsedTime = 0;
> a.play();

This looks pretty cool. Thank god you guys show us a little JS API love :) Looking forward to seeing the API stabilize.
------- Comment #6 From 2011-03-29 11:29:11 PST -------
(In reply to comment #4)
> I think https://bugs.webkit.org/show_bug.cgi?id=54151 might cover this. We need to flesh out the API a little more, but it would be something like:
> 
> var a = myElement.webkitGetAnimation()[0];
> a.pause();
> a.elapsedTime = 0;
> a.play();

I don't believe this will solve the problem since the event will fire asynchronously. Because of this, it will be too late by the time the JS code is executed.
------- Comment #7 From 2011-03-29 12:15:14 PST -------
Correct. You simply cannot rely on DOM events for accurate timing (whether in animations or not).

But the bug was about restarting an animation within the same JS cycle (so that you can avoid setTimeout). The code above would do that.