Jump to content
Search Community

Overwrite tween feature request

TyZ test
Moderator Tag

Recommended Posts

(See: http://forums.greensock.com/topic/7184-oncomplete-event-does-not-fired/)

 

"If you create a competing tween of the same object that's tweening the same property, it will overwrite the previous one by default, and if that previous one has no tweening properties left, it will also kill the tween so that its onComplete doesn't fire."

 

Sometimes this can be very annoying and can (potentially) break your project since there can be a lot of logic dependent on the onComplete call of a tween. Could you please add the following overwrite options:

 

1. Don't kill tweens that doesn't have properties, but still have an onComplete (or an other method) handler.

2. Throw an error when you create a second tween on an objects, when the first isn't finished yet.

Link to comment
Share on other sites

Thanks for the suggestions...

 

1) You can easily accomplish that already by using a simple delayedCall() for your onComplete instead of attaching it directly to a tween that's handling other properties. Like:

TweenLite.to(obj, 1, {x:100, y:200});
TweenLite.delayedCall(1, yourOnCompleteFunction);

Or you can use a TimelineLite:

var tl = new TimelineLite();
tl.to(obj, 1, {x:100, y:200}).call(youOnCompleteFunction);

There are several other ways to do it too, but I don't want to overwhelm you.

 

2) We definitely don't want to throw an error in those situations because it's not an error - many times it's extremely convenient to have the engine handle the overwriting like that (in fact, the vast majority of the time it's ideal). Imagine a simple rollover/rollout button tween - if the user rolls over/out quickly, would you really want an error generated? Would you expect the developer to manually manage keeping track of the original tween and killing it before he starts a new tween with similar properties? One of the most loved things about GSAP is that it "just works" - it handles a lot of cumbersome/ugly/complex stuff under the hood in a performant way and lets you write less code. 

  • Like 2
Link to comment
Share on other sites

Thanks for the quick answer.

 

Your solution means a different way of doing tweens, which would be hard (or even impossible) when working on a big project with a lot of developers and frameworks.

 

The problem now is that a tween can kill the logic of an other tween without warning. If this occurs it's very hard to find or debug. It would be really nice if we could at least get some feedback (like a trace warning or something) that TweenLite killed a tween with an onComplete callback. This can be something which is disabled by default, but could be turned on (during development). So a developer knows why his project is broken.

Link to comment
Share on other sites

We'll consider this for a future release. It's a tough balancing act, though, between packing in tons of features and keeping file size down and ensuring performance is top-notch. If every time a tween gets overwritten it also has to dispatch an event or check for a callback, it can slow things down. We have written the overwriting algorithm to be extremely fast for lookups. I certainly see your point about it being useful to know if/when overwriting occurs. 

  • Like 1
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...