[bug?] Reversed tween is not symmetric in repeatDelay

[Skid X]

Hi,
let's say we have a tween moving an element from point A to point B. We have repeat = 2 and repeatDelay = 1s.
When it plays in forward direction, it goes from A to B and then executes the repeatDelay while staying at point B (the end point of the tween). After the delay, it jumps back to A for the next loop.

Ok, when it plays in backward direction, it goes from B to A but then, instead of executing the repeatDelay staying at point A (its end point in that direction), it jumps immediately back to its starting point B, waiting there for the repeatDelay.
So it seems to me that the reversed version of the tween is not the symmetric with the forward one.
Am I wrong?

is there any way - I don't now, maybe some config param - for forcing it to have the same behavior in reversed direction?

Here you can find an example of the issue. Just click on the div in order to let it go forward or backward.

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

 

[Carl]

Thanks for the clear explanation and demo. 

Both very helpful. 

 

You will most likely get a more official answer later, with a workaround if one exists.

 

I can definitely see how you could want and expect the behavior you are after, but I'm guessing that this is by design, simply because when a tween reverses it respects the easing, timing and positioning that were executed while it played forward.

 

So when the box sticks at the B-point during the delay playing forwards, it seems logical that it would stay in that same position on the return (reverse) trip. 

 

Just wanted to chime in with some thoughts. If there is a way around it, or simply another way to structure your tween we will let you know.

 

Thanks again for the demo, and again I can see why you would want it to work differently.

[Skid X]

So when the box sticks at the B-point during the delay playing forwards, it seems logical that it would stay in that same position on the return (reverse) trip.

 

Yeah, this is totally reasonable and it's the reason for the question mark after "bug" in the title, because from two different points of view both the behaviors (the current one and that one expected by me) seem correct.

 

Anyway, I'm ok with the current behavior in most of the situations, but I would like to find a way to achieve the other behavior too, if there is one, so suggestions will be very appreciated.

 

Thank you very much for the quick reply.

[GreenSock]

Yep, Carl is correct - that isn't a bug at all. It's imperative that GSAP animations run EXACTLY the same in reverse (in every way including easing). That's part of what makes the system so solid - everything remains perfectly synchronized across the board.

 

There's no simple way to just tell the repeatDelay to behave differently in reverse; my suggestion would be to simply create a different tween that does what you want. You could toggle between playing either one based on your needs. Another option is to create a TimelineMax with callbacks at the key spots where you want to have the thing jump, and inside your callback run conditional logic like if (this.reversed()) {...} else {...}. You can definitely get the effect you desire, one way or the other. 

[Skid X]

Ok, the timeline + callbacks solution seems the easiest way.
Thanks for the advice.

Since we are talking about it, I've another question if you don't mind.
Apart from this specific case, making an "emulated" delay with a timeline that contains a callback + a tween (without delay) does imply any valuable overhead in respect to achieve the same result with a single tween with delay?
(let's say using always this solution, so potentially for a significant amount of simultaneous tweens)

I'm asking because I find the Timeline object much more versatile in most of the situations, so I'm wondering if I could use it also if it is not strictly needed without compromising the overall throughput of my script.

[GreenSock]

Technically-speaking, nesting things in a timeline means there's one extra method call on each tick (per timeline), but things are highly optimized in there, so in reality I'd be shocked if you noticed any real-world difference unless maybe you have thousands of simultaneous tweens/timelines running. 

 

And actually, grouping things in timelines CAN be even more efficient in some cases because of scheduling efficiencies and how things are checked. For example if there are 100 tweens on a single timeline, it has to check each one on every render to see if it's supposed to run at that time. If you group 20 tweens into 5 timelines, that master timeline only has to check 5 timelines. If one validates as needing to run, it checks its 20 tweens accordingly. It may sound like a lot of work, but it's actually super fast with linked lists and some other efficiencies we've built in. 

 

In summary, I'd probably prioritize easing your workflow rather than obsessing about a millisecond here or there in JS execution (which, again, you probably wouldn't notice). 

 

As always, I'd suggest doing your own tests.

[Skid X]

great.

In fact I've never noticed any slowdown using your libs in my real cases (except on some old low-cost mobile devices, but there I'm sure it wasn't an issue related to one or more callbacks added), but just to be sure it doesn't imply lot of stuff internally.

Thanks for the clear explanation.