Comments on: Simple Animation

By: Jeff Watkins

Jeff Watkins — Thu, 19 Jul 2007 01:37:49 +0000

Well, I didn't say I wasn't going to have an Animator object. Just that the individual animation steps weren't objects. Take a look at my Animator class. It's still under development, but you'll get where I'm coming from.

By: Karl G

Karl G — Tue, 17 Jul 2007 20:02:07 +0000

I figured you knew, I'm just interested in the different approaches people take. I found the complexity/cycle burning to be a common feature of a number of things in dojo. Supposedly this is better in the current release...

As for the reason to roll your own, I can empathize. My adventure started out when they added a Scriptaculous port to MochiKit. I tried making my own animations and was greatly annoyed at how hard it is. I then ran across Animator.js, was impressed, and decided to port it to MochiKit and make the same animation work on multiple elements. That's great until the elements have different starting values. Things cascaded from there to where I am today.

I am curious about the no-object design decision. Doesn't lacking an animation object force you into maintaining the state elsewhere? Or do you set up your code so this isn't a problem?

By: Jeff Watkins

Jeff Watkins — Tue, 17 Jul 2007 19:12:37 +0000

Thanks for the good points, Karl. I didn't intend to lay claim to anything particularly novel. I'm well aware of how the major libraries implement animation. The main reason I've been writing my own animation code is because the framework provided by Dojo (which is what the online Apple store uses), is incredibly complex and burns a lot of cycles for no benefit.

You're very right that the real fun comes when you put together meaningful chunks of animation.

By: Karl G

Karl G — Tue, 17 Jul 2007 18:55:17 +0000

For the interested, this is more or less the core of every javascript animation engine.

The big variance is on how you define animations and how they are put together. The one-off nature of the animation, rather than keeping the setup stored in an object for reuse, is unique among the js animation frameworks that I know about. Animator.js, which is the framework closest to this approach that I know of, and Dojo.fx (I believe) uses the subject iteration approach shown here while moo.fx and (I believe) YUI use the factory approach mentioned. Scriptaculous avoids this by simply rewriting the animate() method for every type of animation.

Apologies for the vagueness above, it's been almost a year since I looked at the code for the above.

The bulk of the code in these libraries (except for scriptaculous) lies in helping set up the 'actions' array mentioned here and in supplying pre-made easing functions. To use my library -- MochiKit.Animator** -- as an example, 50% of the code is in converting input to subjects (actions) and 25% is easing functions. Most of the rest is used in handling chained animations and minimizing the number of calculations performed at each animation step when multiple objects are animated. The animation core, which is more or less identical to the one shown here, is about 10% of the total.

** My library is one of the heaviest. I think only scriptaculous and dojo are larger and they provide preset animations while I do not. It's optimized towards creating complex one-off animations, which I do frequently, while this one and most others are optimized for reusing a library of simpler canned animations. By way of comparison, the code at the top for fadeIn and fadeOut in my lib would be: fade = partial(cssAnimation, "opacity: 0;");