I’m happy to announce the release of GTween v2. This version is a ground up rewrite of the library focusing on size, speed, extensibility, and improving the readability of the code.
The core library is now just 3.5kb, and it’s 2-5X faster than beta 5 was. GTween now has a simple, but reasonably robust plug-in model, and much of the secondary functionality has been moved out into plugins (ex. snapping, smartRotation, filter support). This has simplified the code a great deal, and made it much easier to understand.
This release comes with a bunch of plugins for common tweening tasks like color adjustments (saturation, hue, etc), synching timeline animations, working with color transforms, run-time calculated motion blurs. It’s also the first release to include a set of easing classes that are optimized for use with GTween.
Finally, this version includes an experimental static interface called GTweener (inspired by Joshua Granick), which provides basic override capabilities.
You can get more information, view demos and documentation, or download the latest version at gskinner.com/libraries/gtween.
What about TweenLite? If you’re curious about what this release means for my relationship with Jack Doyle and the TweenLite library, I invite you to read my blog post on that very topic.
Congrats … very interested in testing this out… I thought you and Jack had decided to work together?
Nice library, will definitely use at one point.
One nice feature would be to enable multiple callbacks at the same position. The small gap workaround just seems a bit hackish.
I noticed that you changed it from an event based model to a callback based one? Why did you decide to go with this syntax instead? I was always under the impression that dispatching events was favorable to passing callbacks?
Awesome stuff, Grant. Just checked out the demos, and now I’m looking for an excuse to use this project.
Christian
sharvey – it is a bit hackish. It’s a bit of a tradeoff between the likelihood that people will actually need multiple callbacks on the same time versus the additional architecture required to support it. I might look at it again if I have time.
Fred – this was purely a performance tradeoff. Callbacks are a lot less flexible, but I had to weigh the benefit of multiple subscribers against the performance cost of callbacks, and chose to favour the latter.
Tiny and fast is hard to pull off. I’m definitely going to check this out. Thanks for all your work!
about to give it a try in an upcoming project. somewhat short timeline… will i be in trouble?
Denis – I’ve had a few people test it out, and v2 seems like the most stable and predictable release so far.
Grant – we shall see 🙂 i’ll twitter-spam you for bugs 🙂
Tweening alpha on object initially set to visible = false now fails?
chris – you need to enable the AutoHidePlugin:
AutoHidePlugin.install();
There was a small bug with the original release of the plugin that would prevent it from changing visible to true when a tween started with alpha=0, but that is fixed in the latest version.
I like the new Version including the inspirations from Joshua.
From the last Version i had make a port from your examples for FlashDevelop. Its not really comfortable without Flash CS, but possible 😉
I would like to make it with the new examples to. Is it possible(allowed) that I publish this port on the FlashDevelop Forum?
After the rewrite it would be easy to port the examples to Flex too.
Thomas – I release everything in MIT specifically so that people can do whatever they want with the code. The examples should be a lot simpler to work with this time around – they are all in class files. Most of them should compile in Flash Builder without any edits.
Hey Grant,
It’s looking great so far. I definitely have experienced speed increases since your last version, so the optimizations have paid off.
I’m benchmarking it alongside my new tween library (Actuate) as well as some other tween engines, and I’m wondering if I’m using the best syntax for this new version?
GTweener.to (p, t, { x: dx, y: dy, alpha: 0.8 } ).onComplete = function ():void { tween (p, dx, dy, t) };
I hate to pass a generic function as a complete handler, but I need to pass parameters onComplete in order for the test to work properly, and yes, I know I’m using your GTweener class rather than instantiating GTween directly — where possible, I’m trying to tweens with overwriting enabled.
http://www.eclecticdesignstudio.com/code/actuate/particledemo2/
It’s interesting to compare and see how everything stacks up, features aside.
However, I would like to mention that BetweenAS3 has no overwrite support, and some of the other libraries support overwriting by target by not by property, but one of the beautiful thing about having so many different libraries is that each one is built for a purpose, and complement different types of tasks and developers. These are key needs for me in my work but not for everyone.
Good job! I excited to see what innovation continues to occur in the community, and fun to see that GTweener got “adopted” 🙂
Joshua – You can use the data property for this. Anonymous functions are very slow. Something like:
new GTween(null,1,null,{onComplete:handleComplete,data:{foo:7}});
function handleComplete(tween:GTween):void {
trace(“data I need: “+tween.data.foo);
}
Thanks for your quick reply. I recompile the swf with SWF Quicker to see the as classes, that was the reason for my question. With MIT it’s no Problem. I will inform you if it’s ready.
I updated the test to handle GTween this way. Passing the tween in the complete handler is a clever idea.
The original demo I was using was built for BetweenAS3, and made use of BitmapData and Point objects to create the animation. Although this looked cool, I decided to modify it to better match a real-world for tween libraries.
The test currently consists of 500 Sprites, which animate their x, y and alpha values, the three most common properties I use in my work. When the tweens complete, they fire a complete handler which resets the Sprite it was tweening and restarts the animation. Of course, I could use “repeat” if I needed to do this in an actual project, but I figured that generating new tween instances was a more appropriate test.
Thanks for your support as usual. Is it too much to ask if it could be open-source (with public repository and ticketing system where anyone can help to improve it)? 🙂
Best, chr
Thanks for your support as usual. Is it too much to ask if it could be open-source (with public repository and ticketing system where anyone can help to improve it)? 🙂
Best, chr
THANK YOU! I was tweening a couple dozen objects simultaneously using the Flash Tween class, and it was a huge CPU hog and inaccurate. I am now using GTween and rotating in 3D and it works freakin great, and my core duo doesn’t complain. Thanks again!
Hi. My opinion. I had chosen GTween ‘cose of the standard flash propagation event. I know that they (Flash.event) are now under a lot of complains but, in my opinion they are so clear! Now I’ve to change again and come back (but where? there are hundreds of tween engine out there!) Do you not belive guys it’s time to open a discussion and REDUCE the number of tween system to ONE or TWO!!! Cheers.
How do you recommend synchronizing multiple tweens now?
How do you recommend creating progress points now?
Thank you for the update!
Erik – Check out GTweenTimeline. It can synchronize and sequence multiple tweens, and has callbacks, which are very similar to progress points.
I have migrated to V2 for mylated project in development and there are a couple things I wish GTween had:
1)multiple calbacks at the same time;
2)IGTweenPlugin.uninstall to get rid of unused plugins once I am done with them;
3)a solution to prevent all the addCallback() callbacks being called twice – for a second time when GTweenTimeline reaches the end. Currently I fixed this by commenting line 317.
And I also wanted to tell that timeScale helped me a lot, I like the new approach of setting tween properties directly to the instance, the event callbacks return tween and not Event and that you are doing this. Thanks a lot!
edzis – thanks for the feedback. I’ll try to incorporate it when I have a chance.
(1) I think that _referenceTime is no longer needed?
(2) When using a GTweenTimeline, my added tween’s setValue’d variables are being set to NaN before the gotoAndPlay tweening starts.
Below is item (2) in a test case. Look at the resultant traces for the NaNs at the beginning.
public class test extends Sprite
{
private var _twnline:GTweenTimeline;
private var _twn:GTween;
private var _h:Number;
public function tmpa( ):void
{
stage.align = StageAlign.TOP_LEFT;
stage.scaleMode = StageScaleMode.NO_SCALE;
_h = 0;
_twnline = new GTweenTimeline( this, 0, {}, {autoPlay:false} );
_twn = new GTween( this );
_twn.setValue( “h”, 1 );
_twn.duration = 1;
_twnline.addTween( 0, _twn );
_twnline.calculateDuration( );
_twnline.gotoAndPlay( 0 );
}
public function set h( v:Number ):void
{ trace(“set h: ” + v);
_h = v;
}
public function get h( ):Number
{ trace(“get h: ” + _h);
return _h;
}
}
There’s a bug with the blurFilter plugin – when I repeat the tween, it reapplies blur filters, instead of setting the blur, effectively stacking blur effects
In the code snippet
// unreferenced tween, in one line:
new GTween(myTarget, 2, {x:50, alpha:1}, {ease:Sine.easeInOut});
// referenced tween, typed properties:
var myTween:GTween = new GTween(myTarget, 2);
myTween.setProperty(“x”,50);
myTween.setProperty(“alpha”,1);
myTween.ease = Sine.easeInOut;
is the property meant to be:
myTween.setValue(“x”, 50);
Just wandering?
in the code snipet
// unreferenced tween, in one line:
new GTween(myTarget, 2, {x:50, alpha:1}, {ease:Sine.easeInOut});
// referenced tween, typed properties:
var myTween:GTween = new GTween(myTarget, 2);
myTween.setProperty(“x”,50);
myTween.setProperty(“alpha”,1);
myTween.ease = Sine.easeInOut;
when you set a value should it not read
myTween.setValue(“x”,50);
Just wondering?
What is the nature of the “garbage collection issues” mentioned on http://blog.greensock.com/tweening-speed-test/ ?
GTween v2 works super for me on repeated uses, and I’ve not seen any memory creep using the profiler.
Erik – Jack mentioned this to me, and I’m not sure yet. My own speed tests build huge numbers of GTween instances (thousands per second), and I have not encountered this problem. I’ll be looking at Jack’s code in the next few days to try to figure out what’s happening.
Erik – it turned out to be a simple bug in Jack’s GTween test. Easy to fix, and he’s uploaded a new version now.
is it possible to implement overwriting by target in V2 in addition to overwriting by property?
i had to opt out in favor of tweenlite for the current project, it just behaved better. maybe with the next version…
GTweenTimeline Why did not call the onComplete?