Question

I’m using jquery animate() to pull values from svg markup, and create an animation. (IE doesn’t support SMIL, so it needs to be done with script.)

Here’s the issue: the animation has thousands of elements, each with their own start time, and so the for loop I’m using to iterate over each element consumes a few seconds, and even more on slower machines/browsers. So it feels like by the time the event queue actually starts, the runtime has already been chugging for a while, and a few seconds have already passed, so the very beginning of the animation jerks ahead. The animations start at time=zero. The beginning of the animation is sometimes being clipped off.

Different browsers seem to handle this differently, and it also seems to depend on the state of the processor, so it’s hard for me to figure out systematically what is happening.) Also this is my first foray into both animation and monstruously long runtimes, so I’m sure I’m doing something wrong 🙂

So my specific question is how to avoid this behavior. But more generally, does the event queue’s timer start at the beginning of runtime or at the end? How does this work exactly?

Here’s most of the relevant code:

function runAnimation() {
  // create node list of paths
  var allPaths = document.getElementById('svgcontainer').getElementsByTagName('path');

  // define the animate function
  var doAnim = function(currentPath, dur, begin) {
    setTimeout(function(){
        $(currentPath).animate({'stroke-dashoffset': 0}, dur);
    }, begin);
  };

  // iterate through the nodelist
  for (var i=0; i<allPaths.length; i++) {

    var pathAnim = allPaths[i].firstChild;

    startTime = parseFloat(pathAnim.getAttribute('begin'));
    pathDuration = parseFloat(pathAnim.getAttribute('dur'));

// change times from seconds to milliseconds        
    startTime = startTime * 1000;
    pathDuration = pathDuration * 1000;

    doAnim(allPaths[i], pathDuration, startTime);
  }
}

Answer 1

Because javascript is single threaded, if you start an animation (which probably does a setTimeout() for some short period of time in the future) and then you run a bunch of other javascript that takes way, way longer than that first setTimeout(), then the setTimeout() won’t be able to fire/run until after your other javascript is done executing. When it does finally run, it will realize that holy-cow, it’s way, way behind schedule and any decent tweening algorithm will attempt to get back on schedule and skip a bunch of the initial part of the animation. This sounds like what you describe seeing.

The only way around this is to avoid any significant time of running code after you start the animation because it’s that code running that puts the animation behind schedule. If you were willing to optimize the start-to-end animation process just for this problem and it’s your own animation code that you can change, you could run through and initialize every single animation such that all initial state was pre-calculated, but none of the actual animations were started. Then, once all the code was run to set up all the animations, you’d run one very fast loop to start them all running. This would minimize the code running time after the first animation was started.

I don’t really know what’s taking all the initialization time now and haven’t benchmarked where the time is really going, but you could optimize your current function like this by precalculating all the initial animation parameters, storing them all into an array and then starting all the animations after you’ve done all that precalculation like this:

Idea #1:

function runAnimation() {
  // create node list of paths
  var allPaths = document.getElementById('svgcontainer').getElementsByTagName('path');

  // define the animate function
  var doAnim = function(currentPath, dur, begin) {
    setTimeout(function(){
        $(currentPath).animate({'stroke-dashoffset': 0}, dur);
    }, begin);
  };

  var anims = [];

  // iterate through the nodelist
  for (var i=0, len = allPaths.length; i<len; i++) {

    var pathAnim = allPaths[i].firstChild;

    startTime = parseFloat(pathAnim.getAttribute('begin'));
    pathDuration = parseFloat(pathAnim.getAttribute('dur'));

// change times from seconds to milliseconds        
    startTime = startTime * 1000;
    pathDuration = pathDuration * 1000;

    // accumulate animation parameters, but don't start animation yet
    anims.push([allPaths[i], pathDuration, startTime]);
  }

  // now start all animations as fast as possible
  for (var i = 0, len = anims.length; i < len; i++) {
      doAnim.apply(this, anims[i]);
  }

}

To be honest, this code change doesn’t look it would be a big savings (there isn’t a lot happening in this code that could take lots of time), but if there size of the loop is big, it could be a meaningful improvement.

---

Idea #2:

Here’s another idea. Sort the animations and call doAnim() on the animations with the quickest startTime last. This makes it less likely that a setTimeout() will want to fire while we’re still initializing animations.

function runAnimation() {
  // create node list of paths
  var allPaths = document.getElementById('svgcontainer').getElementsByTagName('path');

  // define the animate function
  var doAnim = function(currentPath, dur, begin) {
    setTimeout(function(){
        $(currentPath).animate({'stroke-dashoffset': 0}, dur);
    }, begin);
  };

  var anims = [];

  // iterate through the nodelist
  for (var i=0, len = allPaths.length; i<len; i++) {

    var pathAnim = allPaths[i].firstChild;

    startTime = parseFloat(pathAnim.getAttribute('begin'));
    pathDuration = parseFloat(pathAnim.getAttribute('dur'));

// change times from seconds to milliseconds        
    startTime = startTime * 1000;
    pathDuration = pathDuration * 1000;

    // accumulate animation parameters, but don't start animation yet
    anims.push([allPaths[i], pathDuration, startTime]);
  }

  // sort array so that smallest startTime values are last
  anims.sort(function(a, b) {
      return(b[2] - a[2]);
  });

  // Now start all animations as fast as possible
  // Because the array is sorted, it will start the longer setTimeout()
  // calls first and lessen the chance that the short ones will not get
  // get to fire when they want to
  for (var i = 0, len = anims.length; i < len; i++) {
      doAnim.apply(this, anims[i]);
  }
}

Beyond this, any other fixes would probably have to be in the .animate() code itself as it has it’s own setup time so if too many objects are all trying to start their animation at the same time, that won’t be smooth.

---

Notes about how SetTimeout() works with the Event Queue:

Here’s how setTimeout() works with the javascript event queue. A system timer is scheduled for some time in the future. When that time is reached, an event for that timer is put into the javascript event queue. If the javascript engine is idle at that moment, then the corresponding callback is executed immediately. If the javascript engine is executing something else at the moment, then that timer even just stays in the event queue. When the currently executing javascript thread finishes its execution, it checks to see if there are any more events in the event queue. If there is an event waiting, it pulls the oldest one off the queue and starts executing it. The process repeats until when a javascript thread of execution finishes and there are no more events left in the queue. While javascript events can only execute one at a time, new events can be added to the queue in real time as the timer events fire (or mouse clicks happen or keys are hit, etc…).

As you can see, because javascript is single threaded, if there are a lot of things to do all at the same time (like lots of animations to start), then only one of those things will actually start on time and all the others will be delayed some.

In your specific code, if your code is trying to start a whole bunch of animations all at the same time (e.g. all with the same or very close startTime values), then you will start the first one, then the second one will get started, the third one started, etc… and while all those others are getting started, the actual animations aren’t running yet because their timers to actually show the animations are stuck in the queue beyind all the animations trying to get started. The key is to minimize the amount of work that has to happen once any animation is running and to try to spread out the work so no large amount of work is getting done all at once.