Sneak Peek – What’s Next for the GreenSock Tweening Platform
- Version: 10.06, Updated 1/31/2009
- Compatibility: AS3 and AS2
 |
 |
 |
Join Club GreenSock to get bonus classes, updates, and much more
I'm working on the biggest update to the GreenSock tweening platform in a long time, and I'm weighing some fundamental decisions about which I'd like your input. I'm also looking for beta testers. Let me outline the enhancements:
- Shift to a plugin architecture - Most special properties (like "tint", "visible", "frame", "blurFilter", "bezierThrough", etc.) will be separated into optional plugins that can be activated (or not). This makes it possible to only add the features you need and keep file size down and speed maximized. It also means you can author your own plugins to handle whatever special properties you want! If the platform is missing a feature you want, you can probably just write a plugin. And don't worry - you'll still be able to tween ANY property of ANY object without plugins. The plugins only apply to properties that require special handling.
- Eliminate TweenFilterLite - With the new plugin architecture, you can just activate the filter plugins in TweenLite or TweenMax, so I can't see any compelling reason to keep TweenFilterLite around.
- Add "frameLabel" plugin - Allows you to tween to a particular frame label. It's just like the current "frame" feature, but instead of defining a frame number, you define the label.
- Add "setSize" plugin - Allows for easy tweening of component width/height with setSize().
- Add "remove" property to all filter tweens - if "remove" is set to true, the filter will be removed at the end of the tween.
- Add "index" property to all filter tweens - allows you to define a specific index number in the DisplayObject's filters Array where you'd like your filter tween to occur. This is not mandatory - it just provides more flexibility.
- Add "addFilter" property to all filter tweens - when addFilter:true is passed in with any filter tween, it forces a new filter to be used instead of trying to use one that's already there. This is completely optional. Normal behavior is for TweenLite/Max to look for an existing filter of the same kind and tween it but if it can't find one, it creates one.
- Add "transformAroundCenter" plugin - scale, rotate, or move a DisplayObject/MovieClip using its center as the origin, regardless of where the actual registration point is. Imagine dynamically loading an image and then scaling it or rotating it as though its registration point is centered. This plugin is a membership benefit of Club GreenSock.
- Add "transformAroundPoint" plugin - scale, rotate, or move a DisplayObject/MovieClip using any point as the origin, regardless of where the object's registration point is. This plugin is a membership benefit of Club GreenSock.
- Add "colorTransform" plugin - Accommodates advanced color tweening of a DisplayObject's ColorTransform like redMultiplier, redOffset, greenMultiplier, etc. It also adds convenient ways to tween the exposure, brightness, and tint amount (so you can tell it to only tint to 50% for example). This plugin essentially replaces ColorTransformProxy - it is more efficient and less code. It is a membership benefit of Club GreenSock.
- Change "shortRotation" syntax - Previously, shortRotation could only affect the "rotation" property of an object, but that doesn't accommodate 3D rotations well (rotationX, rotationY, and rotationZ). So now you can pass an object with any number of properties that should be affected, like: TweenMax.to(mc, 2, {shortRotation:{rotationX:-170, rotationY:100}}).
- Speed enhancements (20-50% in some situations!)
- Fix some minor overwriting bugs
- Eliminate allTo(), allFrom(), sequence(), and multiSequence() from TweenMax - TweenGroup offers the same functionality, plus a whole lot more flexibility and power.
So here are the questions I'd like your feedback on:
- Should TweenLite have any plugins activated by default?
I like the idea of having it as lightweight as possible by default. It seems fitting since it's "TweenLite". With the new architecture, the core TweenLite class would actually be smaller (2.9k), BUT with the same plugins activated that were included in the old engine ("frame", "tint", "removeTint", "volume", "endArray", "visible", and "autoAlpha"), it would increase the total size to about 5k. If I activate them by default, everything will work in the new version just like the old version without any tweaks, but in a way, it defeats one of the primary purposes of the plugin architecture which is to minimize file size and maximize performance by allowing you to only activate the features you need. Keep in mind that activating a plugin is SUPER-simple and takes only one line of code, like TweenPlugin.activate([TintPlugin]). You only need to do it once in your SWF too. So what's more important? Prioritizing the "Lite" in TweenLite by default or prioritizing backwards compatibility with no activations necessary? Also keep in mind that TweenMax will have most plugins activated by default, so if anyone has trouble with TweenLite, they can just use TweenMax. - Got any general suggestions?
Send 'em my way. Please keep in mind that the primary concern with the classes was to maximize speed and flexibility, NOT to break the code into logical, readable chunks (function calls are expensive performance-wise).
EXAMPLES
-
import gs.*;
-
import gs.plugins.*;
-
-
TweenPlugin.activate([BlurFilterPlugin]); //not necessary if you're using TweenMax, and even with TweenLite you only have to run this ONCE in your SWF.
-
-
TweenLite.to(mc1, 2, {blurFilter:{blurX:20, blurY:5}});
-
import gs.*;
-
import gs.plugins.*;
-
-
TweenPlugin.activate([BezierPlugin, BezierThroughPlugin]); //not necessary if you're using TweenMax, and even with TweenLite you only have to run this ONCE in your SWF.
-
-
TweenLite.to(mc1, 2, {bezierThrough:[{x:200, y:100}, {x:500, y:50}]});
-
TweenLite.to(myComponent, 2, {setSize:{width:200, height:30}});
-
TweenLite.to(mc, 2, {frameLabel:"myLabel"});
-
TweenLite.from(mc, 2, {blurFilter:{blurX:50, remove:true}});
FAQ
- Are the new plugin-based versions of TweenLite and TweenMax backwards-compatible? Will I have to mess with adding activation code to old projects or will it just work?
Don't worry. Everything is backwards compatible with one minor exception: "shortRotation" now accepts an object instead of a number so that you can apply it to multiple properties. Other than that, you shouldn't have any trouble using the new version(s) in older projects. - Is there a way to make TweenLite or TweenMax smaller by only activating a subset of the default plugins?
Absolutely. The default plugins are activated inside the class and I clearly marked them towards the top of the class, so you can simply delete or comment out the ones you don't need. - Why is TweenLite 5k instead of 3k now?
The new plugin architecture cost about 1.5k and about 0.5k went towards some strategies that make the engine even faster, but if you don't need any of the default plugins (autoAlpha, tint, removeTint, volume, visible, endArray, and frame), just delete or comment out the activation lines in the TweenLite constructor to reduce the size to just 2.9k!. Ultimately, the plugin architecture will allow you to minimize file size because you can activate only the plugins you need in your project and you can even add many of TweenMax's features to TweeenLite without the added size associated with TweenMax. - If I activate a plugin, does it affect TweenLite tweens, TweenMax tweens, or both?
Both. And it doesn't hurt anything if you activate plugins more than once. It doesn't help either. - How do I build my own plugin?
Just read the instructions in the comments at the top of the gs.plugins.TweenPlugin class. Hopefully it's pretty straight-forward. - Do I have to purchase a license to use this code? Can I use it for commercial purposes?
Donations are not mandatory, but I do ask that you consider joining Club GreenSock which gets you some bonus classes (only available to club members), update notifications, and more. Your donations keep this project going. TweenLite and TweenMax are free for virtually all uses except in commercial products/sites for which end users must pay a fee of some kind to use or access. Please see http://blog.greensock.com/licensing/ for details.
Need Help?
Feel free to post your question on the forums. You'll increase your chances of getting a prompt answer if you include a simplified FLA file (and any class files) that clearly demonstrates the problem and provide a brief explanation.
Copyright 2009, GreenSock, Inc.
"NO CHARGE" NON-EXCLUSIVE SOFTWARE LICENSE AGREEMENT
-----------------------------------------------------------------------------
PLAIN ENGLISH SUMMARY:
- You may use the code at no charge in web sites, games, components, applications, and other software as long as end users are not charged a fee of any kind to use your product or gain access to it. It doesn’t matter if you are paid to create the site/product. If you charge end users a fee, you must sign up for a corporate Club GreenSock membership which comes with a commercial license granting you permission to do so. See http://blog.greensock.com/club/ for details.
- Since the code is updated frequently and developers are best served by having the latest version, please avoid (or at least minimize) distributing the source code outside your organization.
- Use at your own risk. I offer no warranties.
- Please respect the copyright.
-----------------------------------------------------------------------------
LEGALESE:
This is a legal agreement between you (either an individual or a single entity) and GreenSock, Inc. ("GREENSOCK") for the proprietary GreenSock ActionScript code known as TweenLite, TweenMax, TweenGroup, OverwriteManager, and other code that is freely available for download at http://blog.greensock.com or http://www.greensock.com (this code and documentation, as well as any updates which may at GREENSOCK's sole discretion be provided to you from time to time, are referred to in this Agreement as "PROGRAM") By installing, copying, or otherwise using the PROGRAM, you agree to the terms and conditions of this Agreement. If you do not agree to the terms and conditions of this Agreement, please do not install or use the PROGRAM.
I. LICENSE
A. Subject to the terms and conditions of this Agreement, GREENSOCK hereby grants you a non-exclusive, worldwide, non-transferable right to use the PROGRAM in web sites, games, applications, components and other software for which the end user is NOT charged any fees. If you would like to use the code in a commercially licensed software product for which end users are charged a fee (either for usage or access), simply sign up for a corporate Club GreenSock membership at http://blog.greensock.com/club/.
II. LIMITATION OF LICENSE AND RESTRICTIONS
A. You agree that you will not disclose, sell, rent, license, or otherwise distribute the PROGRAM's source code or any derivative works thereof to any third party without the prior written consent of GREENSOCK. Derivative works are defined as modifications that add substantive functionality to the PROGRAM and do not include bug fixes or other minor modifications required to operate the PROGRAM as originally intended. Limited distribution of the source code to vendors as part of your Work Product is acceptable so long as they agree to the terms of this Agreement. You agree not to modify or delete GreenSock's existing copyright notice located in the source code.
B. You may use, duplicate, and distribute the compiled object code solely as embedded in a Work Product created by you, either for your own use or for distribution to a third party so long as end users of the Work Product are not charged a fee for usage. Please see http://blog.greensock.com/licensing/ for descriptions of Work Products that qualify for the "No Charge" license.
III. CONSIDERATION
A. The license rights granted to you under this Agreement are at no charge, but only in the following circumstances: If, either on your own behalf or on behalf of a third party, you incorporate the Software into a web site, software application, program or any component thereof (collectively, “Work Productâ€), which in the case of a web site, must be accessible to internet users without payment of a fee of any kind by a user, and in the case of a software application, program or component, neither you nor anyone to whom you distribute the Work Product charges a user a fee of any kind to use such Work Product or application, program or component into which such Work Product is embedded. The foregoing shall apply regardless of whether you are paid to create such Work Product and, under any circumstances, shall be subject to the prohibition against distribution of Source Code set forth in Section II.
B. In the event your intended use of the Software does not meet the criteria for the “no charge†license rights set forth in the immediately preceding paragraph, then you are not licensed to use the PROGRAM under this Agreement and must license the PROGRAM under GreenSock’s separate fee-based Software License Agreement which is granted to corporate Club GreenSock members (see http://blog.greensock.com/club/ for details).
IV. TITLE AND OWNERSHIP
A. The PROGRAM is licensed, not sold, and is protected by copyright laws and international treaty provisions. You acknowledge that no title to the intellectual property in the Software is transferred to you. You further acknowledge that title and full ownership rights to the PROGRAM, including all intellectual property rights therein, will remain the exclusive property of GreenSock and you will not acquire any rights to the PROGRAM except as expressly set forth in this Agreement. You agree that any copies of the PROGRAM you make will contain the same proprietary notices which appear on and in the PROGRAM.
V. DISCLAIMER OF WARRANTY AND LIMITATION OF LIABILITY
A. THE PROGRAM IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. GREENSOCK DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE PROGRAM WILL MEET YOUR REQUIREMENTS OR THAT OPERATION WILL BE UNINTERRUPTED OR ERROR FREE. GREENSOCK shall not be liable for special, indirect, incidental, or consequential damages with respect to any claim on account of or arising from this Agreement or use of the PROGRAM, even if GREENSOCK has been or is hereafter advised of the possibility of such damages. Because some states do not allow certain exclusions or limitations on implied warranties or of liability for consequential or incidental damages, the above exclusions may not apply to you. In no event, however, will GREENSOCK be liable to you, under any theory of recovery, in an amount in excess of the license fee paid by you under this Agreement. Notwithstanding anything else in this agreement, you agree to indemnify GREENSOCK, its assignees, and licensees, and hold each of them harmless from and against any and all claims, demands, losses, damages, liabilities, costs, and expenses, including legal fees.
B. GREENSOCK may, at its sole discretion, provide support services related to the PROGRAM, but has no obligation to do so.
VI. TERMINATION
GreenSock may terminate this Agreement at any time if you fail to comply with the terms and conditions of this Agreement.
VII. MISCELLANEOUS
A. This Agreement shall be construed in accordance with the laws of the State of Illinois. Should you for any reason bring a claim, demand, or other action against GREENSOCK, its agents or employees, arising out of this Agreement or the PROGRAM licensed herein, you agree to bring said claim only in the Illinois Court of Claims.
B. THIS AGREEMENT REPRESENTS THE COMPLETE AND EXCLUSIVE STATEMENT OF THE AGREEMENT BETWEEN GREENSOCK AND YOU AND SUPERSEDES ALL PRIOR AGREEMENTS, PROPOSALS, REPRESENTATIONS AND OTHER COMMUNICATIONS, VERBAL OR WRITTEN, BETWEEN THEM WITH RESPECT TO USE OF THE PROGRAM. THIS AGREEMENT MAY BE MODIFIED ONLY WITH THE MUTUAL WRITTEN APPROVAL OF AUTHORIZED REPRESENTATIVES OF THE PARTIES.
C. The terms and conditions of this Agreement shall prevail notwithstanding any different, conflicting, or additional terms or conditions which may appear in any purchase order or other document submitted by you. You agree that such additional or inconsistent terms are deemed rejected by GREENSOCK.
D. GREENSOCK and you agree that any xerographically or electronically reproduced copy of this Agreement shall have the same legal force and effect as any copy bearing original signatures of the parties.
| I'd like to donate & get bonus classes, update notifications, SVN access, and more. |
on December 24th, 2008 at 6:36 pm
I think it’s a good idea to remove the filters TweenFilterLite because we can activate them in TweenMax and TweenLite.
on December 24th, 2008 at 8:16 pm
Should TweenLite have any plugins activated by default?
yes i think that some plugins like: “frameâ€, “tintâ€, “removeTintâ€, “volumeâ€, “visibleâ€, and “autoAlpha†features should be activated by default.
——————————————–
With the new architecture, the core TweenLite class would actually be smaller, BUT with the same plugins activated that were included in the old engine, it would increase the size by about 1.5k – is it worth the trade off?
I prefer 1.5 k plus but more flexibility with the new architecture
——————————————–
Should TweenFilterLite be eliminated?
Yes why keep duplicate feauture?
——————————————–
Got any general suggestions?
Yes, please o please, do not cut off the as2 version development as there are many graphic users who aren’t familiar with as3 :-)
on December 24th, 2008 at 9:12 pm
Sounds like some great ideas there! I look forward to using the most advanced form of the best tweening engine I’ve ever used! Keep up the great work!
on December 27th, 2008 at 4:58 pm
Should TweenLite have any plugins activated by default? – yes, keeping the same default features enabled would probably make the transition a lot smoother for everyone. At least If developers wants to shave k by turning them off, they can.
Is it worth the tradeoff? – easily.
Should TweenFilterLite be eliminated? – yep, no need to support (and make more work for yourself) it if there’s better ways to do things now.
The frameLabel thing is great, that’s going to be a huge help when dealing with the designer/developer workflow.
on December 29th, 2008 at 4:57 am
I like the idea of using a plugin architecture. It’s very seldom I use more than one filter so being able to activate that filter for Tweenlite would be great. And that means of course that there’s no need for TweenFilterLite.
I don’t know about those special properties (tint, visible etc.). I do use them often so it would probably take some getting used to if they weren’t activated by default, but I could live with it if you think it’s the best way to go.
If it helps getting even better speed then I say go for it – especially if they are activated in TweenMax.
Is it worth the tradeoff? – Yes
on December 30th, 2008 at 4:54 am
That’s a great idea to switch to a plugin based architecture. Is there any way to auto-activate certain filters? For instance calling “autoAlpha” would first check if the plugin is activated before proceeding.
From the newly proposed plugins, I like “frameLabel” the best, because it would remove the need to update any code after changing the duration of an animation in the timeline.
Looking forward to your enhanced Tweening library!
on December 30th, 2008 at 5:44 pm
I think it’s pretty much a must to have tweenlite have all the default features enabled by default otherwise this will pretty much break every single application that relies on tweenlite. And it’d be quite a pain to backtrack 50 projects and update the code in all of the classes for each :/
on December 30th, 2008 at 5:58 pm
Hi, Jack!
I just read your interview with Evolve on that blog. It’s good to hear that you’re a man of faith and moreover that I’m not alone in this community :)
Anyway, I just wanted to leave a comment saying thanks for the good work, and I felt encouraged by reading your interview. Hope this doesn’t come across as spam not relevant to the post :)
I think the plugin based architecture sounds awesome. It keeps things loosely coupled, turning the important things on. @Rich, there’s not really a way to turn plugins off after they’re already turned on, MXMLC compiles them into your SWF if they’re referenced at all. They’d have to all be off at first then activated by hand by the developer to ensure small filesize.
– TK
on January 2nd, 2009 at 6:51 pm
Is the plugin architecture worth it? Yes, absolutely!
Should TweenLite have any plugins activated by default?
Yes, but I don’t think it needs to be all of the current ones. For our shop, we only use TweenLite for banner work where every kilobyte counts. We almost always use autoAlpha and tint, so it would be nice to have those enabled by default. Occasionally we use the frame property for banners, but not often. It would be nice to reduce the filesize of TweenLite or keep it about the same, even if it meant less plugins turned on by default.
For non-banner work, an extra 4k (or however much) is a drop in the bucket when you’re building a 100k+ flash page. Then we use TweenMax anyway. It might make sense to enable more of (if not all) the current special properties in TweenMax with the exception of the filter properties. That would make it easy for developers not as equipped to deal with change, while maintaining a commitment to small filesize in TweenLite.
on January 7th, 2009 at 1:16 pm
this stuff looks great! i’ll trust you to decide whether some plugins should already be activated or not, i’d be happy either way. just out of curiousity, why are tint and removeTint separate plugins? do you expect people would really want one and not the other?
on January 7th, 2009 at 1:37 pm
Brandy, good question. The reason “tint” and “removeTint” are separated has to do with two things: 1) The strict typing in TweenLiteVars won’t allow a uint or Number to be null, so if you’re using TweenLiteVars, you couldn’t just do tint:null, meaning a separate property/value was required, and 2) Every plugin is associated with ONE keyword that it searches for in the vars object, so we need separate ones for “tint” and “removeTint”.
on January 7th, 2009 at 7:36 pm
This is a great idea. What are the differences between TweenLite and TweenMax, under the new framework? In other words, what additional features of TweenMax are NOT handled by plugins, and why not?
on January 7th, 2009 at 8:12 pm
Great question, Dave. I should have made that more clear in my post. There are several capabilities TweenMax adds to TweenLite which can’t be added with plugins, like pause(), resume(), restart(), reverse(), setDestination(), invalidate(), killProperties(), timeScale, globalTimeScale, progress, roundProps (technically a plugin but it only works with TweenMax instances), event listeners, and then management features like getAllTweens(), pauseAllTweens(), resumeAllTweens(), killAllTweens(), killAllDelayedCalls(), isTweening(), and getTweensOf(). The only way to add these capabilities with a “plugin” of sorts is to make the class dynamic and stick methods/properties on at runtime, but that’s a bit messy and it’ll tick off the folks who rely on code hinting when they code (very common).
on January 9th, 2009 at 4:07 am
hey Jack, I thought we were just about at the end of tween engine development, and boom…you come up with this now.
- We prefer every old Tweenlite feature activated by default for backward compatibility.
- Optimization comes towards the end of the project, so it’s easier to disable features we don’t need to save kilobytes than think forward and possibly have errors because of features not activated.
on January 9th, 2009 at 4:41 pm
Hi jack_
Big fan of the classes. I like this move. I would have to agree that if you killed tint by default it would break a lot of my existing code.
Perhaps the new architecture calls for a new class with no defaults. this could replace TweenFilterLite in the triad.
I know that’s a tough marketing decision because everybody knows the project as TweenLite, but I think it would be worse to break backwards compatibility.
As for the name? TweenSock? TweenLyt? Ugh. Its a real conundrum. TweenAir? <– Apple-ish, but sounds like your open-source competitor.
Hm, maybe TweenLt. I vote TweenLt. its lighter than Light, and looks just right. Plus I have a paralysed hand so less typing is always a plus :P
Best,
_b
on January 11th, 2009 at 9:08 am
Hi!
I am not a big fan of the activate, I loved the Moesesupposes tweening engine – until he made the “register”, which is like activate.
I love the fact that using TweenLite/Max doesn’t require setup or any static settings. Just use it.
If I am running 40 classes in a project which all uses the tween – then I have to either have one single class to add in the “plugins”, or to set this in every constructor of every classes.
I am not fond of that, but for TweenLite – which I see is perfect for small files – such as banner – here the plugin-atchitecture could be great – so you could add the special properties you need…
for now though, I love TweenMax, and when doing campaigns that are from 2mb+, the size of the TweenMax is no problem at all, it is already really light AND powerful.
I love the other features, the FrameLabel is great to have, adds extra additional features for developer-designer/animator working in same files.
on January 14th, 2009 at 7:01 pm
Hi Jack,
If activation of plugins is possible with only 1 line of code, then I would say that keeping file size to a minimum in TweenLite is important. That is, unless the user has to activate a large number of plugins to achieve what they want. But in that case, those people will probably be better off using TweenMax anyway.
on January 25th, 2009 at 6:28 am
Love the new transformAround….plugins. Great idea and very useful.
Maybe I’m slow but is the endArray not new as well ?
Can anyone give any examples of useful real world examples of that ?
And just to be sure im heard :o) – I vote for no plugins activated by default.
on January 25th, 2009 at 10:18 am
Hey Torben. Actually, endArray has been there almost since the beginning. It’s probably not something you’d use a lot, but it can be quite handy for tweening things like the “matrix” Array of a ColorMatrixFilter or 3D transform matrices, etc. And yeah, I think the transformAround…plugins will be much more convenient than TransformMatrixProxy (unless you need to skew something). They’re faster too.
And regarding activating plugins by default in TweenLite, the vast majority of developers seem to be more concerned with backwards compatibility than shaving off 1.5-2kb by default. I see their point. The last thing I want is for users to download the new version (without realizing they may need to activate some plugins) and get really frustrated when something doesn’t work. Plus there are lots of examples out on the web with code that requires the plugins and one of my primary concerns is user-friendliness, so I’m leaning strongly towards leaving the plugins activated by default and letting folks deactivate them if necessary for saving kb.