Jump to content
Search Community

Competing progress() calls inside of resize

zachschnackel test
Moderator Tag

Go to solution Solved by OSUblake,

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

Hi all!

In the attached CodePen, I have a reduced test-case of a UI I'm working on. On desktop-view (768px and higher) if you click the "Open Convo" button, the Inbox and Convo panels will both be on the screen by manipulating their `flex-basis`. If you then click the "Open Profile" button (enabled when you click the "Open Convo" button on desktop, you'll see the entire `.app-panels` transform over to show that area.

 

I have a slightly different UI if you interact with the panels on mobile (767px and lower --- do a refresh to interact with mobile and just drag the window in smaller so the other timelines run don't conflict <-- one of the things I'm trying to fix).

 

If you go through the same steps as mentioned above, you'll notice just the `.app-panels` div transforms to show the full-width version of each panel within it -- which all works fine.

 

Now -- refresh and start with the desktop-view again and open the Convo. What I'm doing in the resize listener `optimizedResize.add()` is checking if the convo desktop timeline has been run by using `progress()` and if it is complete and on-resize if it's in a mobile-view, I want to set the progress of the desktop timeline back to the beginning and then set the progress of the mobile timeline to 1 (or finished). I have a `clearProps` helper in the `onReverseComplete()` callback of the desktop timeline, but the ending prop styles of the desktop timeline still remain, so it messes up the mobile-view.

 

I know that's kind of a cluster-f*ck to throw at ya, but hopefully that's a good enough explanation. I'm not sure if it's an issue with editing the state of GSAP timelines within a resize event or if it's the nature of calling the `progress()` function of two timelines that could override each other. Let me know if you need anymore clarifications. Thanks for checking this out!!!

See the Pen d15a0b4bad1c6ed25ac327db68d67606?editors=0011 by zslabs (@zslabs) on CodePen

Link to comment
Share on other sites

  • Solution

Hi @zachschnackel,

 

Not sure if I totally understand your issue, but here's how I handle resizing. I record the state of an animation, usually it's progress value and reversed state, but it all depends on the animation. For a repeating animation that yoyos, I would just record the totalProgress.

 

Next, I set the progress of the animation to 0 and clear it. That should prevent any inline styling issues. Finally, I rebuild the animation, and set the state of the animation to the values I recorded earlier. The performance impact of creating new animations is minimal, and is something I would not worry too much about unless you notice it's an issue. Rendering is the bottleneck 99% of time, not your JS.

 

Here's a simple demo of how that looks.

See the Pen 3f8b76a324743b25b786026d5b711fff?editors=0010 by osublake (@osublake) on CodePen

 

And here's a more advanced demo using some media query listeners. 

See the Pen ee36b4d9caaea7e27815cd5f7f76d14c?editors=0010 by osublake (@osublake) on CodePen

 

.

  • Like 3
Link to comment
Share on other sites

Those examples are awesome! Thank you as always for the support and willingness to help explain. Have a great day!

 

For anyone else that references this later, you can follow along in that pen, but Blake's examples may be a bit more straight-forward to consume.

  • Like 1
Link to comment
Share on other sites

Another nice trick that may help you in the future with resizing/layout changes is setting the progress an animation to 1 to calculate an end value. Just a couple simple examples...

https://greensock.com/forums/topic/12241-get-end-value-of-classname-tween/?p=50574

https://greensock.com/forums/topic/16334-thishittest-in-ondragend-but-for-final-position/?p=71904

 

.

Link to comment
Share on other sites

Hey Blake - I think I have  working about 99.9%, but for some reason while re-sizing and interacting with the panels, the resize listener gets in a weird state where it will be "off" what it should calculate to. It's a bit sporadic, so I'm not sure if it's an issue with `progress()` (if it's asynchronous) or what, but something gets confused after a number of interactions.

Link to comment
Share on other sites

It's almost as-if some of the checks around the `progress()` are being checked twice before GSAP has enough time to update. Since my resize listener also runs during requestAnimationFrame (as does the GSAP ticker) I wonder if things are getting confused in there...

Link to comment
Share on other sites

The only thing that stands out to me at the moment is that you are creating a new timeline after clearing one, so that might be the double checks you are describing. If you look at my examples, I'm not creating any new timelines. Yes, I do create new timelines in that grid demo, but that's only if a timeline doesn't already exist. 

Link to comment
Share on other sites

Ah! They do not -- they set them back to their original values, but still inline them. So -- what I did was run `TweenMax.set(panelSelectors, { clearProps: 'all' });` to make sure those are 100% clean before setting the progress of other timelines. Thanks for your help!

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