Jump to content
Search Community

TweenMax.fromTo cancel inconsistency.

jdoleary test
Moderator Tag

Go to solution Solved by GreenSock,

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I have found what seems to be an inconsistency when cancelling tweens.  Please see the attached codepen for a demo.

 

Usual Behavior:  When TweenMax.set is called while another tween is running, the already running tween is cancelled (when they affect the same values)

 

The Possible Bug:  When that initial tween is called, but it hasn't "started", the cancellation does not occur and TweenMax.set is effectively called before the former tween even though it occurs after.

 

Edit:  I updated the codepen to work and to make more sense.

See the Pen wMKbqM?editors=101 by jdoleary (@jdoleary) on CodePen

Link to comment
Share on other sites

Hello jdoleary, and Welcome to the GreenSock Forum!

 

Your codepen is not working. Your example is missing your jQuery selector to be a string $(".test"), instead of $(tests) .. since test var is not defined.

 

So you have this:

var tests = $(tests);

But it would need to be this:

var tests = $(".test");

Here is your original codepen that will run now with the above change, for others who need to test jdoleary original codepen:

 

I don't believe this to be a GSAP bug.. but just the way from() tweens work, since from tweens run immediately by default, and have immediateRender: true by default.

 

This helpful video tut might help clear some things about from(), fromTo(), staggerFrom(), and staggerFromTo() tweens and immediateRender

 

 

Also in the TweenMax Docs, as well as the TimelineMax Docs... check out he overwrite special property .. auto is default

  • "auto" (2) - when the tween renders for the first time, it will analyze tweens of the same target that are currently active/running and only overwrite individual tweening properties that overlap/conflict. Tweens that haven't begun yet are ignored. For example, if another active tween is found that is tweening 3 properties, only 1 of which it shares in common with the new tween, the other 2 properties will be left alone. Only the conflicting property gets overwritten/killed. This is the default mode and typically the most intuitive for developers.

overwrite : String (or integer) - Controls how (and if) other tweens of the same target are overwritten. There are several modes to choose from, but "auto" is the default (although you can change the default mode using theTweenLite.defaultOverwrite property):

  • "none" (0) (or false) - no overwriting will occur.
  • "all" (1) (or true) - immediately overwrites all existing tweens of the same target even if they haven't started yet or don't have conflicting properties.
  • "auto" (2) - when the tween renders for the first time, it will analyze tweens of the same target that are currently active/running and only overwrite individual tweening properties that overlap/conflict. Tweens that haven't begun yet are ignored. For example, if another active tween is found that is tweening 3 properties, only 1 of which it shares in common with the new tween, the other 2 properties will be left alone. Only the conflicting property gets overwritten/killed. This is the default mode and typically the most intuitive for developers.
  • "concurrent" (3) - when the tween renders for the first time, it kills only the active (in-progress) tweens of the same target regardless of whether or not they contain conflicting properties. Like a mix of "all" and "auto". Good for situations where you only want one tween controling the target at a time.
  • "allOnStart" (4) - Identical to "all" but waits to run the overwrite logic until the tween begins (after any delay). Kills tweens of the same target even if they don't contain conflicting properties or haven't started yet.
  • "preexisting" (5) - when the tween renders for the first time, it kills only the tweens of the same target that existed BEFORE this tween was created regardless of their scheduled start times. So, for example, if you create a tween with a delay of 10 and then a tween with a delay of 1 and then a tween with a delay of 2 (all of the same target), the 2nd tween would overwrite the first but not the second even though scheduling might seem to dictate otherwise. "preexisting" only cares about the order in which the instances were actually created. This can be useful when the order in which your code runs plays a critical role.

But Carl and Jack can clarify this for you :)

  • Like 2
Link to comment
Share on other sites

I really shouldn't do any heavy thinking on a Monday.  :lol:

 

Regarding the OP's question. Isn't this a matter of the set() actually firing before his fromTo() ?

 

Even though that set() is listed after the initial tween and you'd think it would overwrite the tween, the set() actually fires at time 0 and the fromTo() starts on the first tick of the timeline?

 

I'm not sure if that is correct, but it seems similar to my post last week with the nested timelines that had a set() at time 0.

Link to comment
Share on other sites

  • Solution

From what I can tell, this isn't a bug. Let me explain...

 

fromTo() tweens do indeed have immediateRender set to true by default, but we don't apply overwriting immediately in that case because doing so would have negative/unintuitive consequences. You may have various tweens with delays or scheduled inside timelines that won't actually start running until much later - the immediateRender is just to force an initial render and place the properties at specific values. The overwriting occurs when that tween actually starts running for the first time. I think that may be the heart of the confusion here. 

 

The fromTo() is set up (and renders its initial state). It is not considered to be "running" yet (until the next tick). This is very intentional because when a tween is created, it may then get inserted into a timeline and scheduled for later. So we can't just assume that a fromTo() tween with no "delay" should be considered active/running. Then in your example you do a set() which of course runs IMMEDIATELY. It doesn't find any other tweens that are instantiated and fully active yet, so it doesn't overwrite anything. On the very next tick, your fromTo() tween says "hey, let's go...my playhead started moving." and that's when overwriting occurs.

 

I hope that clears things up. If you have a particular use case that's causing trouble, let us know and we can help you get the results you need. Your codepen seems like an edge case that's pretty unlikely to occur in the wild, but again, we can help code around whatever issues you're running into :)

  • Like 3
Link to comment
Share on other sites

Hi All,

 

Sorry for the broken pen, I cleaned it up before posting and stupidly forgot to test it again.

 

@Jonathan, @Jack,
This is kind of what I assumed was going on.  I guess "intuitive" can mean different things in different examples.  I just so happened to expect that a call to "set" would overwrite any previously called tweens on these objects, but I can see why you want it that way.

  • Like 1
Link to comment
Share on other sites

 

overwrite : String (or integer) - Controls how (and if) other tweens of the same target are overwritten. There are several modes to choose from, but "auto" is the default (although you can change the default mode using theTweenLite.defaultOverwrite property):

  • "none" (0) (or false) - no overwriting will occur.
  • "all" (1) (or true) - immediately overwrites all existing tweens of the same target even if they haven't started yet or don't have conflicting properties.
  • "auto" (2) - when the tween renders for the first time, it will analyze tweens of the same target that are currently active/running and only overwrite individual tweening properties that overlap/conflict. Tweens that haven't begun yet are ignored. For example, if another active tween is found that is tweening 3 properties, only 1 of which it shares in common with the new tween, the other 2 properties will be left alone. Only the conflicting property gets overwritten/killed. This is the default mode and typically the most intuitive for developers.
  • "concurrent" (3) - when the tween renders for the first time, it kills only the active (in-progress) tweens of the same target regardless of whether or not they contain conflicting properties. Like a mix of "all" and "auto". Good for situations where you only want one tween controling the target at a time.
  • "allOnStart" (4) - Identical to "all" but waits to run the overwrite logic until the tween begins (after any delay). Kills tweens of the same target even if they don't contain conflicting properties or haven't started yet.
  • "preexisting" (5) - when the tween renders for the first time, it kills only the tweens of the same target that existed BEFORE this tween was created regardless of their scheduled start times. So, for example, if you create a tween with a delay of 10 and then a tween with a delay of 1 and then a tween with a delay of 2 (all of the same target), the 2nd tween would overwrite the first but not the second even though scheduling might seem to dictate otherwise. "preexisting" only cares about the order in which the instances were actually created. This can be useful when the order in which your code runs plays a critical role.

But Carl and Jack can clarify this for you :)

 

Jonathan,

 

I tried using "overwrite" to correct the problem but it still didn't work.  Also, I don't think this is a case of "immediate render" confusion because I'm using fromTo and not just from, so the object's values when the function is called are irrelevant.

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...