Jump to content
GreenSock

trsh

Is this a GSAP timeline bug?

Recommended Posts

Hi.

 

First of all - I welcome me in GSAP community :)

 

The second thing, that I have a problem with GSAP timeline functionality (check the codepen).

 

Is it a bug? When second timeline is removed, in my opinion, it should not reserve the time for it. Especially not after invalidate().

 

Any suggestions for workarounds?

See the Pen bZoGAE by anon (@anon) on CodePen

  • Like 2
Link to comment
Share on other sites

Hi trsh,

 

I'm with you here, confused as I think I expected the behaviour as you seem to be expecting. Trying to understand the reason why it isn't but I guess we will have to wait for someone else to answer.

  • Like 1
Link to comment
Share on other sites

Hello trsh and Welcome to the GreenSock Forum!

 

Just so we know.. What is the expected behavior you want, so we have a better idea the type of movement you want in your animation?

 

In what order? If you can list the movement it should follow.

 

Any additional information will help us in helping you!

 

Thanks :)

  • Like 1
Link to comment
Share on other sites

Hi trsh,

 

Welcome to the forums.

 

Great job on providing a clear demo with your question!

 

The behavior is not a bug. Timelines do not auto-collapse or move children around when you pull an animation out of the middle.

 

If you want to shift tween3 to start at the end of tween1 the shiftChildren() method will help.

 

docs: http://greensock.com/docs/#/HTML5/GSAP/TimelineLite/shiftChildren/

 

var tl = new TimelineMax({paused: true});

var tween1 = TweenMax.to(el, 2, {x: 100, y: 100});
var tween2 = TweenMax.to(el, 5, {x: 200, y: 200});
var tween3 = TweenMax.to(el, 2, {x: 0, y: 0});

tl.add(tween1);
tl.add(tween2);
tl.add(tween3);

tl.remove(tween2);

tl.shiftChildren(-tween2.duration(), false, tween2.duration());

http://codepen.io/GreenSock/pen/mEBVow?editors=0010

  • Like 4
Link to comment
Share on other sites

Let me completely hijack this thread as I am quite interested in this behaviour and how GSAP handles removal of children.

 

I did some testing on the demo trsh provided and noticed the total duration of timeline did not change. So, it goes with what Carl has explained that timelines do not auto-collapse if you remove the tween and thus, the behaviour the original pen was displaying matches the explanation.

 

Checking the total duration of Carl's demo, I can see it gets updated and reflects the removal and shifting of the remaining children which, would be the behaviour I expected from the .remove() method. I imagine, trsh also expected such behaviour.

 

Now, given that you have the timelines updating its total duration (and everything else) with a .add() method, and that you can have the same by doing a .remove() and .shiftChildren(), wouldn't it be possible to have the .remove() shift the remaining children in the timeline automatically?

 

I would say, it does make it more intuitive to have the timeline updating itself by shifting all the children after the removed tween, rather than having the gap where such tween was previously.

  • Like 1
Link to comment
Share on other sites

 

Hi trsh,

 

Welcome to the forums.

 

Great job on providing a clear demo with your question!

 

The behavior is not a bug. Timelines do not auto-collapse or move children around when you pull an animation out of the middle.

 

If you want to shift tween3 to start at the end of tween1 the shiftChildren() method will help.

 

docs: http://greensock.com/docs/#/HTML5/GSAP/TimelineLite/shiftChildren/

 

var tl = new TimelineMax({paused: true});

var tween1 = TweenMax.to(el, 2, {x: 100, y: 100});
var tween2 = TweenMax.to(el, 5, {x: 200, y: 200});
var tween3 = TweenMax.to(el, 2, {x: 0, y: 0});

tl.add(tween1);
tl.add(tween2);
tl.add(tween3);

tl.remove(tween2);

tl.shiftChildren(-tween2.duration(), false, tween2.duration());

See the Pen mEBVow?editors=0010 by GreenSock (@GreenSock) on CodePen

 

 

Hi. Thanks. This explains my problem right on the point.

 

In addition, In my opinion the default behavior should be the auto-collapse. With option to not do that -> tl.remove(tween2, [true]), because there are NOT a lot user cases, where you really want to keep the gap. And lot of new users will get confused. Just read other answers in this post :)

 

Thanks again!!!

  • Like 1
Link to comment
Share on other sites

....

 

I would say, it does make it more intuitive to have the timeline updating itself by shifting all the children after the removed tween, rather than having the gap where such tween was previously.

 

I Agree. Its more intuitive and more user-cases. But a option to keep the GAP should be there. 

Link to comment
Share on other sites

Even more impressive would be if you were able to tween out the gap, by either running all children behind the removal forward for the duration while keeping the children before it paused. Or vice versa.

Link to comment
Share on other sites

Thanks for the suggestions. We are very hesitant to bloat the core with features, that although are useful to some, are rarely used. This is especially true in cases where the api already supports workarounds. In the case of closing the gap you can just use shiftChildren() as illustrated above.

 

Tallwhitey, your suggestion of stretching out the tweens before the removal is certainly interesting but again I'd imagine its an extremely rare use case.

To achieve that effect I suspect you could remove those tweens, but them in another timeline, and then change that timelines duration() to whatever you want and drop that timeline back into the original. Entirely possible but quite a bit of code (kb) to add to the core. 

 

We will definitely appreciate the feedback and suggestions. I can't deny that having the timeline's auto-collapse would be a cool feature. We will chew on this some more and keep an ear out for similar requests. Of the thousands of issues / requests posted in this forum its just very rare to hear anything related to remove() and we are just very cautious about adding features that affect file size. 

  • Like 2
Link to comment
Share on other sites

Yeah I assumed this was a very edge case but it appealed to the "is it possible" part of me ;) 

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