Jump to content

Search In
• More options...
Find results that contain...
Find results in...

# Negative timeline progress not working

## Recommended Posts

I'm pretty sure I was able to set negative progress in gsap2, but it doesn't seem to be working in gsap3. Any thoughts?

See the Pen NWPPVKg by sallf (@sallf) on CodePen

##### Share on other sites

Indeed it was:

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

What are you needing a negative progress value for?

##### Share on other sites

Was that depreciated in gsap3?

Similar to my recent post, I'm working on bringing a slider based on OSUBlake's draggable infinity slider up to gsap3.

See the Pen veyxyQ by osublake (@osublake) on CodePen

In `updateProgress()` `transform.x` is usually a negative value, which is what's being passed to `animation.progress(...)`. Looking closer, I didn't realize that progress will always compute to a positive number between 0 and 1. That logic makes sense and means I can just do the progress logic myself (something like const `trans = transform.x > 0 ? (1 + transform.x) : transform.x;`) before passing it to `progress()`.

I think I had a general misunderstanding of the logic there and assumed it might be a bug in gsap3 since it worked that way in gsap2.

##### Share on other sites

@GreenSock might be able to provide some insight, but I don't think it's necessary for GSAP to support a negative progress value. As you point out it can be worked around. Thanks for bringing it up!

##### Share on other sites

Ya, I don't think so either now that I understand it better.

Also, for anyone following along, I think the actual work around for this situation is something like this (not what I had above):

```let transPerc = transform.x / wrapWidth;
transPerc = transPerc - Math.floor(transPerc);
const trans = transPerc > 0 ? transPerc + 1 : transPerc;

animation.progress(trans);```

Thanks for the quick replies!

• 2
##### Share on other sites

Yep, in v2 there was extra code to FORCE the value to be 0-1 but in v3 I eliminated that code for several reasons:

1. To allow things to genuinely go negative, meaning the startTime of the animation could shift in a more flexible way (rather than always forcing the animation to be within range of the parent timeline's playhead)
2. Less code = smaller file, less CPU cycles

And you're absolutely right - it'd be easy to get the behavior you wanted with a little extra code. ?

• 2

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