Jump to content
Search Community

POLL - TweenMax and GoASAP

GreenSock test
Moderator Tag

Should TweenMax be built on top of the GoASAP framework?  

26 members have voted

  1. 1. Should TweenMax be built on top of the GoASAP framework?

    • Yes, the convenience/flexibility of GoASAP is worth the file size and speed trade offs
      3
    • No, I prefer the improved speed and size of the current version of TweenMax
      23


Recommended Posts

Moses Gunesch has created a very fast, lightweight core AS3 animation framework that he's proposing as a standard of sorts. You can learn more about it at http://www.goasap.org. He's done a great job of making it fast, but due to several factors I won't go in to right now, TweenMax would be slower if it was built on the GoASAP framework. It definitely wouldn't be a good fit for TweenLite because it would more than double the file size. In fact, here are some benchmarks I ran:

 

GoASAP-based size: 6600 bytes

TweenLite size: 3096 bytes

 

GoASAP-based speed (without overlap checking): 45.5fps

GoASAP-based speed (with overlap checking): 3.9fps

TweenLite speed (with overlap checking): 51.7fps

 

As you can see, the speed was somewhat close when I turned off the overlap monitor but since by default, TweenLite overwrites competing tweens of the same Object, it seems necessary to turn that on. It’s not an apples-to-apples comparison with the overwriting, though, because TweenLite takes an "all or nothing" approach (overwriting all pre-existing tweens of the same Object OR not overwriting any if you set overwrite:false) whereas I believe the GoASAP framework checks each individual property for overlaps. Also, Moses has been kind enough to take on the job of optimizing the code for use with his engine (and tweaking his engine to make it work better with TweenMax), so the speed gap will likely get even smaller, especially the overlap checking - my version may have implemented it incorrectly or something because those numbers seem way out of whack. In the end, the GoASAP version may only be 1 or 2 fps slower when pushing around 1500 instances which is pretty darn good.

 

Since TweenMax isn't so concerned about file size, it would be the only engine of mine that I'd consider building on GoASAP. So if the GoASAP-based version is slower and fatter, why would I even consider it? Well, as Moses explains, it can be very convenient to have a single core engine that's driving everything in your SWF. For example, if you had a physics engine and a 3D engine and a tweening engine running on a common framework and you wanted to pause everything, you could do it in one place instead of 3. Plus it could be convenient to have all the systems synchronized so that when an UPDATE event is dispatched, you know that the physics, 3D, and tweening values have all been updated.

 

I'd like to serve you well, so please let me know what you think - should I rework TweenMax so that it's built on top of the GoASAP framework? Are the speed and file size trade offs worth the increased flexibility and convenience?

Link to comment
Share on other sites

  • 2 weeks later...

more speed is always good, filesize I would have a little more flexibility on. Tough call. I use TweenLite & TweenMax because they are lightweight and efficient I'd hate to give up any of that - they're perfect just as they are.

 

The real question is: Will goASAP take off - if it becomes real popular or a de facto standard then yes, I would want the option to use TweenMax as my tweening engine.

 

I'm going with a NO vote, with qualifications.

 

BTW, I couldn't find any licensing info on the goasap site, licensing is a huge issue for me.

Link to comment
Share on other sites

TweenMax is good the way it is. Small, easy and fast. The only improvement I would like to see is to be able to create an object out of a tween instance, add tweens to (with timings relative from previous tween) and start() it. Much like Fuse does. I was a Fuse user until I learned about TweenMax and it's small size and high performance.

Link to comment
Share on other sites

The only improvement I would like to see is to be able to create an object out of a tween instance, add tweens to (with timings relative from previous tween) and start() it.

 

Every time you call TweenMax.to() or TweenMax.from(), you're actually creating an object. You can keep track of it like this:

 

var myTween:TweenMax = TweenMax.to(my_mc, 2, {x:"300"});

 

And it starts automatically, but you can always pause() it and resume() later. Or for even more control, use the progress property. For example, to make it skip to half-way through, you can set myTween.progress = 0.5.

 

And if you want to set up a sequence, look into the sequence() and multiSequence() methods. Lots of options :)

Link to comment
Share on other sites

Jack,

we vote for small filesize and speed, don't care about the underlying framework.

It'd be nice to have an SVN repository though, especially if you're rolling out updates so fast.

cheers, Marton

Link to comment
Share on other sites

I think having you building a tweener on GoAsap would be absolutely great for advanced tweening capabilities. I'm not really worried about having more Kb for a library and I'm sure it won't be that much. The job you have done on your Tween family is really good, especially in a real work process, some properties has been just really thought, such as delay increment or similar.

 

Instead of changing the TweenMax, why not build a TweenMaxGo (there's already a TweenGo I think)?

 

Everyone would be happy choosing what they need between Tweenlite, TweenMax and the Go version. Moses has done an amazing work on his engine and having you develop a parser on it would be IMHO The Tweener to use.

Link to comment
Share on other sites

I'm dismayed the results of this poll so far do not support GoASAP. I can certainly see why people want TweenMax to run as fast as possible, but I can also see great value the ability to make an integrated tweening and physics engine, and I'd prefer to use TweenMax for the tweening. Maybe this poll isn't framing things in the best way. Ideally, TweenMax would remain TweenMax, and there would also be a separate GoTweenMax. I understand if this entails too much work.

 

Personally, if I have to chose, I'd prefer GoTweenMax over TweenMax, because TweenLite already exists for those applications that require high speed above all other features. Not to mention, the speed difference is only apparent when you use an obscene number of simultaneous tweens. I'm curious, how real is the need for a tweening engine with the additional features TweenMax has over TweenLite, plus the slight additional speed TweenMax has over say HydroTween? How many projects exist which simply cannot make do with TweenLite, and also have the gargantuan number of tweens necessary to take advantage of this slight speed advantage of a TweenMax NOT built on GoASAP? Maybe I'm biased for my own work experience, but I have a hard time imagining many situations like that.

 

I have a much easier time imagining all the exciting possibilities of using TweenMax's concise, intuitive syntax and powerful features seamlessly with a physics engine or 3D renderer. I guess in my mind, TweenLite will take care of those with a need for blistering speed and small file size, while TweenMax should look to the possibilities of the future, which includes GoASAP.

Link to comment
Share on other sites

the speed difference is only apparent when you use an obscene number of simultaneous tweens.

 

Actually, that's not entirely true. The speed difference can be very important even with one or two tweens. Imagine two buttons next to each other with Tween-based rollovers. If the user rolls back and forth between them, speed is very important to ensure there's no perceivable lag time in the rollovers/rollouts.

 

I'm curious, how real is the need for a tweening engine with the additional features TweenMax has over TweenLite, plus the slight additional speed TweenMax has over say HydroTween? How many projects exist which simply cannot make do with TweenLite, and also have the gargantuan number of tweens necessary to take advantage of this slight speed advantage of a TweenMax NOT built on GoASAP?

 

I had the exact same thought for quite some time actually. But people kept asking for more advanced features, especially filter and bezier tweening. I brushed 'em off for a while, but eventually they wore me down and I created TweenMax :-) Now it seems to be getting quite popular. I really want to minimize the trade offs developers face when "upgrading" to TweenMax. File size probably doesn't matter that much, but if the speed drops off significantly, it becomes very unattractive. It's a balancing act.

 

I'm not opposed to using GoASAP. I certainly see some benefits, but I also see trade offs which may not be acceptable to the user base. That's why I started this poll in the first place - to see what the consensus was. It seems like speed is extremely important to folks and outweighs the convenience factor of building on top of GoASAP (so far).

 

It may sound easy to just crank out another "GoTweenMax" class, but I've learned the hard way that it's a lot of work to maintain and support. Every time I add a feature to one, I'd need to add it to the other and work within two different frameworks. I'd also need to adjust things as Moses (and others) update the core GoASAP framework which takes even more time and increases the chances of bugs. I'd much prefer to pick a route and go with it as opposed to maintaining and supporting two TweenMax variants.

 

I appreciate all the input guys. I'll keep the poll open for a while more, so encourage your friends to vote.

Link to comment
Share on other sites

  • 2 weeks later...

My opinion:

Only build TweenMax on top op GoASAP if the drawbacks are negligable.

So at least not at this moment.

It might be a good idea to identify the factors that would slow down TweenMax and contact Moses Gunesch about these to maybe come to a solution that would satisfy both parties.

Ofcourse it would always be a good idea to have both a GoASAP and a non-GoASAP version of the classes so the developer can decide for his-/herself which version to use.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...