Jump to content
Search Community

Issue in V3: play() resets playdirection as set with timescale [v3.2.4]

Friebel test
Moderator Tag

Recommended Posts

When setting a negative timescale to let play() play in the reverse direction, the play() method resets the direction and always plays forward.

I understand the difference between play() and reverse() and that play() is there to normally play forward and reverse() to do play in the reverse direction, but when setting a negative timescale the whole thing should reverse in my opinion. So if we set a negative timescale and run play() I would expect the play head to play from the current position backwards  and reverse() from the current position forwards.

 

The way I would expect this to work:

- set the timescale to a negative value to run the thing backwards when play() is called:

- on a call of play() just play the direction that is currently set; so backwards
- on a call of reverse() play the animation in the reversed direction, which is forwards in this case, as the timescale is set to a negative value

 

See the Pen jOPzZwW by Friksel (@Friksel) on CodePen

Link to comment
Share on other sites

First of all, thanks for the demo! :)

 

play() has always forced the playhead to go forward, and reverse() has always made it go backward, and resume() just resumes playback regardless of the direction. I don't think it would be wise to suddenly change that behavior now. Is there some reason resume() won't work for you? 

  • Like 3
Link to comment
Share on other sites

47 minutes ago, GreenSock said:

First of all, thanks for the demo! :)

 

play() has always forced the playhead to go forward, and reverse() has always made it go backward, and resume() just resumes playback regardless of the direction. I don't think it would be wise to suddenly change that behavior now. Is there some reason resume() won't work for you? 

Thanks for your response @GreenSock Jack. Reason I'm coming with these issues is because things related to reverse a timeline direction as made on gsap v2 don't work anymore in v3 (it doesn't reverse). So now I'm figure out why and find these sub issues.

 

I don't really like it when a lib thinks for me on what should happen, to prevent a 'mistake' for me and therefore gets out of the way of other logic as how it is build. I would say that if play() respects the height of the timeScale value, what it does rightnow, than it would be logical to also respect it if a value is zero or negative. When that's not the case I understand it could prevent some problems for other people, but it can also cause issues when things are not working as expected, because it's not using the same logic in every case. So now that's error prone to people understanding the logic, because the logic is not the same everywhere. I would in these cases chose for the same logic everywhere and trust developers on their responsibility a little more.

 

That said; resume() could be a nice alternative though in this case. I will try that out

Link to comment
Share on other sites

@GreenSock Alright, just looked inside the project and unfortunately resume() isn't a solution here, as I need to play from a labels position with play('label'). So unfortunately the issue persists.

 

[edit] Would it be possible to ad an optional function parameter to resume() to be able to set the timeline position to resume from? Just like in the play() method? So without that parameter resume() works as it does now (as I understand it is like play, but except from the logic to reset the timescale/direction), but can be used with a resume-position (like a label) as well.

Link to comment
Share on other sites

Wouldn't it be as simple as:

tl.seek("label").resume();

?

 

30 minutes ago, Friebel said:

things related to reverse a timeline direction as made on gsap v2 don't work anymore in v3 (it doesn't reverse)

I'm a little confused - can you offer more details? Of course a demo would be ideal (that shows a reverse working in v2 that wouldn't work in v3). 

 

I'm not saying you're wrong - I just don't understand, that's all.

 

play() has ALWAYS forced the playhead to go forward, and reverse() made it go backward (including in v2 and v1) - I think that's what throwing me off here. I get that you think GSAP is "wrong" (or at least inconsiderate of smart developers) for behaving that way, and I'd respectfully disagree but even if I totally agreed with you it'd be problematic to alter that behavior now and break all legacy projects. See what I mean? 

  • Like 2
Link to comment
Share on other sites

2 hours ago, GreenSock said:

I'm a little confused - can you offer more details? Of course a demo would be ideal (that shows a reverse working in v2 that wouldn't work in v3). 

@GreenSock I created two codepens. One where I use gsap v2 and one in which I use gsap v3. These simplified demos show the issue I'm facing right now after upgrading. As you can see the animation is perfectly working in version 2, but the expected reverse when hitting the 'OUT' button is not working in version 3 with the exact same code.

 

As you can see in the second demo (using gsap 3) the box is not moving back, but forward when hitting the 'OUT' button.

 

BTW, I wasn't talking about right or wrong or smart/stupid, but about consistent logic vs inconsisant logic and thinking for a developer that uses the lib vs trusting developers and giving them freedom. Seems like my point didn't come across.

 

Demo with gsap 2: 

See the Pen oNXqdKp by Friksel (@Friksel) on CodePen

Same demo with gsap 3: 

See the Pen bGdvYrR by Friksel (@Friksel) on CodePen

 

 

  • Like 1
Link to comment
Share on other sites

Ah, these demos were incredibly helpful, @Friebel! 🎉 Thanks so much for taking the time to put those together. I now see exactly what the problem is, and it also exposed an edge case and allowed me to fix it. Let me explain...

 

Core problem

In GSAP 3, timeScale controls the direction of playback, thus it can be negative. For example, if timeScale is 1 and then you reverse(), the timeScale will be -1. And if you set the timeScale to a negative value, reversed() will report as true. I think this is far more intuitive and logical. It even lets you animate the timeScale from positive to negative and back again. That was impossible in v2. 

 

In GSAP v2, timeScale could NOT be negative. So when you reverse() it had no effect on timeScale. The two values weren't linked at all. I've added a note to the migration guide to make this clear. 

 

In your codepen, you were animating timeScale from 0 to 1 regardless of the direction of playback (reversed or not). That's why the reverse wasn't moving...you called reverse() but then you animated the timeScale from 0 to 1 which of course made the playhead move FORWARD. You should make the timeScale go in the proper direction (negative when in reverse). 

 

Exposed bug

If the timeScale is exactly 0 when you call reverse(), it wouldn't work because -0 is the same as 0 :) Frankly, I didn't anticipate people setting timeScale to 0 much - I figured they'd just call pause() but that was an oversight on my part. In the upcoming release, I've fixed this; preview it at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

 

I also changed the behavior so that if timeScale is 0 when you call play(), it won't jump to a timeScale of 1. That seemed to catch a few people off guard. I thought I was helping (making it more intuitive...I figured people would find it odd if they call play() and it doesn't actually play), but I can now see that was probably not the best option. The next release will just leave timeScale where it was regardless. 

 

Here's a fork of your codepen that shows it working: 

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

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, GreenSock said:

In GSAP 3, timeScale controls the direction of playback, thus it can be negative. For example, if timeScale is 1 and then you reverse(), the timeScale will be -1. And if you set the timeScale to a negative value, reversed() will report as true. I think this is far more intuitive and logical. It even lets you animate the timeScale from positive to negative and back again. That was impossible in v2. 

Ah, that clears things up

 

3 hours ago, GreenSock said:

 

If the timeScale is exactly 0 when you call reverse(), it wouldn't work because -0 is the same as 0 :) Frankly, I didn't anticipate people setting timeScale to 0 much - I figured they'd just call pause() but that was an oversight on my part. In the upcoming release, I've fixed this;

Great extra catch!

 

3 hours ago, GreenSock said:

I also changed the behavior so that if timeScale is 0 when you call play(), it won't jump to a timeScale of 1.

Thanks a lot for this! 😀 That really helps! I'm sure it won't affect many peoples code in a negative way, because when someone found and uses timeScale I think they also know what they're doing and will understand and be glad with this decision!

 

I'm using gsap via npm and webpack, so to test the minified version in the actual project I have to change the structure too much. So as I've seen it working in the codepen, I just wait for the upcoming release and use it via npm. Looking forward to this next version! Thanks again for the quick action!

  • Like 3
Link to comment
Share on other sites

2 hours ago, GreenSock said:

Here's a tarball file that you can npm install to try it in your project: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-beta.tgz

 

Does that work well for you? 

Thanks for the tgz file. Unfortunately this is not fixing the issue in the project here. Still weird things happen with the reverse. The first time reversing is okay, so something has changed, but all next times I press the button to reverse it moves forward again.

 

There is a difference between the simplified codepen I posted and the code I'm using in the actual project though; and that is that in the codepen I just use play() on the animTl without parameters, but in the actual project I add a position to play from. 

 

[edit] This was just a quick test. At the moment I don't have much time to dive into this further. So I'm not sure if I'm missing something that I need to check or change in my code or that the new gsap is still having an issue in reverse when using a position parameter in the play() and reverse() methods. But wanted to give you already this information above.

Link to comment
Share on other sites

Hm, I'm very eager to see a reduced test case if possible because I'd rather not release 3.2.5 without confirming there's not an issue. But in my fork of your demo, it works fine every time I hit the "out" button. I realize your "real" project has other stuff going on, so it must be something else. Tough to diagnose blind, though. 

 

And to be clear, calling reverse() will ALWAYS make the animation go in reverse (negative timeScale) - it doesn't just flip it. In other words, if timeScale is negative when you call reverse(), it doesn't flip it to positive (forward). I know you prefer that, but that would be a major shift in behavior that would ruin backward compatibility (legacy code), so it's not something I want to do. 

 

Looking forward to seeing the demo so we can effectively troubleshoot. 👍

  • Like 3
Link to comment
Share on other sites

On 3/14/2020 at 10:25 PM, GreenSock said:

Looking forward to seeing the demo so we can effectively troubleshoot. 👍

You already have it. It's in this thread already. I even created both an example using gsap v2 as well as an example using gsap v3.

This already IS the demo. What else do you need?

 

As said, in my project I'm doing the exact same thing as done in the example here. The only thing I changed is the update eventhandler, as you did in the changed codepen. But I've checked everything several times now and can't get it to work with the tgz-file you supplied. Eventhough the code should be exactly the same as in the codepen. But, as said, the only difference is that in the 'real' project I'm using a position in the play() and reverse() methods to play from. Are you sure that should also work with the latest beta?

 

I see the minified javascript file (gsap.min.js) inside the tgz package you've sent is the same as the one you use in the codepen. But are you sure also the tgz package contains exactly the same individual module files as well as used in the minified js you use in the codepen? As I'm importing via webpack imports and don't use the minified file.

 

Also please keep in mind this project worked for years with all gsap v2 versions. I see you only changed one thing (the ctrl update function) in the example. So that should also be the only thing I need to change in the real project to make it work in v3 as per logic, I'd think.

Link to comment
Share on other sites

6 hours ago, Friebel said:

You already have it. It's in this thread already. I even created both an example using gsap v2 as well as an example using gsap v3.

This already IS the demo. What else do you need?

I'm totally confused - it works perfectly in the demo above, as evidenced by my fork. And yes, I'm sure that the tarball file uses the updated version. In fact, my local copy is doing standard ES imports (not using the minified file). Works great. 

 

I wonder if you've got a weird caching thing going on in your local environment? 

 

This is what makes it really difficult to troubleshoot - you said that your local version is indeed doing some different things but I don't have access to your files, so I can't reproduce that. I have no way of knowing what's going on, what exactly is different, if it's a logic problem in your code or if it's some other bug. I really want to help...I'm just kinda stuck here. The fix I provided works in the demo you gave us.

 

6 hours ago, Friebel said:

the only difference is that in the 'real' project I'm using a position in the play() and reverse() methods to play from. Are you sure that should also work with the latest beta?

As far as I know, yes. Can you edit my fork and show me how exactly you're using a position in the play()/reverse() methods? Does it work in that codepen? 

 

6 hours ago, Friebel said:

are you sure also the tgz package contains exactly the same individual module files as well as used in the minified js you use in the codepen? As I'm importing via webpack imports and don't use the minified file.

Yep. When you console.log(gsap.version), what do you see? 

 

  • Like 1
Link to comment
Share on other sites

9 hours ago, GreenSock said:

I wonder if you've got a weird caching thing going on in your local environment? 

 

...

 

Yep. When you console.log(gsap.version), what do you see? 

Hi @GreenSock Jack, I ran this code to view the gsap.version and it stated 3.2.4. Which is weird and makes me worried a little bit, because I definitely installed the latest beta version you sent me with success (the console also ended with 3.2.5 installed) and even tested the installed version number afterwards by running `pnpm list gsap`, which showed 3.2.5. Crazy.

 

I now removed the full node_modules folder and did a install from the package.json again. Now it works with no problem. So this was indeed some crazy pnpm cache problem. You say you are confused, but I am as well now. This makes no sense to me.

Last week I switched from npm to pnpm (and also than removed the node_modules folder and re-installed everything, but with pnpm), which is not copying the same modules to every project, but uses things like symlinks for optimization and re-use of modules so it doesn't have to download the same modules everywhere. I wonder if we can fully rely on pnpm and/or if it has something to do with some nasty explorer/win10 issues I'm facing like freezing and sometimes not refreshing explorer-windows since the 2 latest windows 10 updates. My system is clean, secure and fully up to date for sure. Hope that Microsoft will fix these issues soon, as I'm not the only one having these or that I can find a way to somehow solve this or work around myself. But not sure if that's related to this caching issue.

 

Guess I can at least not trust the pnpm install to always work. And not even the pnpm list command obviously. Crazy. On the other hand, a week or two ago I had also a caching problem with npm and gsap, as we found out in these forums. Before that I never experienced any caching issues with npm or yarn and I'm using these for years now. So I'm confused.

So I guess I need to always remove the full node_modules folder now and than running an install, just to install something new to upgrade, which is definitely not the way it should be obviously. Not sure what's causing this.

 

Sorry for this inconvenience. Obviously the 3.2.5 beta fixes the original issue. Thanks for your time and pointing me to gsap.version. That's a nice one to know. Glad it is fixed now in 3.2.5 and guess it's safe to release.

  • Like 3
Link to comment
Share on other sites

On 3/18/2020 at 8:06 PM, GreenSock said:

Ah, thanks for confirming. Very glad to hear that it was just an odd caching thing. Sounds pretty frustrating for you, though!

@GreenSock Jack, I'm very dissapointed right now. The beta version where you had fixed this issue was working fine, but in the released 3.2.5 version (both the standard npm version as well as the bonus package) there are new bugs again which are even worse: making the reverse not doing anything anymore and even crashing the full animation with stutters and flahses and all. I cannot even describe it.

 

This is definitely not a caching issue of pnpm or any other issue here besides gsap. I removed all the pnpm cache, removed the node_modules folder, removed the pnpm lock-file and re-installed everything. But still the released gsap 3.2.5 is having issues that weren't there in the beta version.

 

I even stepped away from pnpm for this project completely just to be sure this is not an issue of pnpm or windows, and went back to npm, which is reliable for years and never let me down. So removed the full node_modules folder of the project and re-installed everything from scratch in this project with `npm install`. With this I am absolutely sure the new gsap package is installed inside the project and this isn't some cache thing.

 

After switching back to the beta everything works again. So it's definitely an issue in the released 3.2.5 version. What's the use of supplying a beta version to test if things are changed for the worse in the release??

 

Last weeks I found a lot of nasty bugs in the lib to a point I really wonder if you even test the lib as these issues are so on the surface. You call these rare cases every time I report one, but I highly doubt these are rare cases. 

 

To be honest I am really getting tired of debugging gsap now and I am done with it. I reverted to the beta version and go look for alternatives. Maybe build a lib myself. That cost me way less time than continues debugging a library I even pay for and by people expecting me to debug issues in the lib they created.

 

Sorry to say, but I pay for gsap to not having to build it myself and don't need to do this myself so I have time to focus on other things, but this costs me so much time and money now to a point I would have created an animation-lib myself for the things I need. I have other things to do and I'm debugging these issues for weeks now. Sorry to say, but it seems like quality control is not what I was used to with greensock. Which is a shame. I feel very dissapointed and I already know how you would react to this. Which makes it even worse.

 

I'm done

Link to comment
Share on other sites

Gosh I just feel terrible about your experience, @Friebel. I'm so sorry. I don't blame you for being frustrated/disappointed.

 

I also want to assure you that I've remained committed to fixing bugs and making GSAP better for 10+ years and I hope you've seen that commitment here as I've responded promptly even on weekends and evenings. This is my full-time job and I take it seriously. I know how many people are relying on GSAP and it's a big responsibility. It always feels like a punch to the gut to read things like your post above. 

 

Let me assure you that we do test things. I have a suite of automated tests that I run every release through plus we do some manual random testing, dropping the new version into various codepens. Your reports have led to at least 6 new automated tests. Again, 3.2.5 passed them. But Rodrigo did find an issue with reverse() right after release, so I've now added a new automated test to sniff that type of thing out in the future. I apologize for that slipping through the cracks. Of course it's fixed in the next release which I'm prepared to push out very quickly but I want to check with you to make sure there's nothing else we need to address first. Can you try the beta and see if it resolves things for you? https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-beta.tgz (that's the tarball you can install).

 

I actually think it might be a good idea for you to try building your own engine or use a different one because it'll illustrate how incredibly difficult, time-consuming, and complex it is. Look how many Github issues are still open with various other open source options...and they often remain open for months/years (or never get fixed). And those are for libraries that are far more simplistic than GSAP. If you build your own, I guarantee you're gonna run into a plethora of surprising challenges with various edge cases. I could rattle off a ton of them that we've addressed over the years. Most people have no idea just how many little "gotchas" we've already solved with GSAP (which other engines haven't). From browser bugs/inconsistencies to logic challenges with engineering a system that'll accommodate infinite nesting of animations and behave intuitively in dozens of tricky scenarios. I'm not the smartest guy around, that's for sure, but I've seen scores of other developers take a crack at something like this over the years and it always fell flat. 

 

Anyway, I'm not looking to get defensive or anything. My main goal here is to always make GSAP better and I'm grateful for the ways you've helped that happen with your bug reports. Seriously, thank you. And again, I'd humbly ask that you'd provide a little more info about your latest challenge so that I can make sure that 3.2.6 is rock solid before pushing it out. I'm eager to do so ASAP. Can you try the beta and confirm it resolves everything for you? If not, please provide details about any problems (ideally a codepen) and I'll jump on fixing whatever needs fixing. 

 

Also, did you say that your app actually CRASHED...as in an infinite loop somewhere? I'm super curious about that. Or maybe you just meant that the reverse() didn't work. Either way, I'm eager to hear any details you can offer. 

 

6 hours ago, Friebel said:

and I already know how you would react to this. Which makes it even worse.

Can you clarify what you mean by this? 

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