Luke Sturgeon – Lab

I wanted to test out the performance of my new and improved Tweeny animation engine. For this all I’ve done is create a simple demo which created 1000 balls and adds them to the display list. Then tweens each to a new random position somewhere on the stage once every 3 seconds. Once the timer stops the experiment traces the lowest framerate that the SYSMonitor (a system monitor component) recorded.

I’ve created 5 seperate examples so that the numbers wouldn’t be affected by previous tweens and used Tweeny, TweenLite, Tweener, gTween and Tweensy. The framerate is 30 fps and I have used exactly the same code in all experiments (in fact all the code is in each one, I just comment and uncomment the tween I want to use).

Tweeny (800×600 @ 30fps)

1. 8 fps
2. 10 fps
3. 10 fps

TweenLite (800×600 @ 30 fps)

1. 9 fps
2. 10 fps
3. 12 fps

Tweener (800×600 @ 30 fps)

1. 9 fps
2. 10 fps
3. 9 fps

gTween (800×600 @ 30 fps)

1. 11 fps
2. 11 fps
3. 9 fps

Tweensy (800×600 @30 fps)

1. 10 fps
2. 9 fps
3. 10 fps

Now these test are pretty consistent across the board, which is actually what I was hoping for. I’m not trying to say Tweeny is far faster than other tween engines out there, it’s not clearly, but it is on par with most of them. In fact, I have to create 1 tween per property I want to animate, which means there’s double the number of tweens running in Tweeny than there are in the other experiments (2000) so the fact that it is not struggling too much and give similar performance to other tween engines in this experiment is great news.

The one other thing I noticed is that out of all of them, the Tweener experiment didn’t seem to show screen refresh glitches whereas the others did. The animation looked much smoother on my screen even though the conditions where identical in each experiment. I’m go to dig around in the Tween code and see if anything special is being done here.