GSDevTools has issues with Timelines with useFrames set to true

[mattkahl]

The attached Codepen is identical to the "GSDevTools - Step 2: Give Animations IDs" example, except that the `tl` Timeline specifies `useFrames` as true.

 

Expected behavior:

"orange", "green", and "grey" should appear in addition to "Global Timeline" in the GSDevTools timeline list.

 

Actual behavior:

Only "grey" appears in addition to "Global Timeline". "orange" and "green" (notably children of the `useFrames` Timeline) no longer appear.

See the Pen gBZZzR by mattkahl (@mattkahl) on CodePen

[GreenSock]

Sorry, but GSDevTools doesn't support useFrames:true animations. That feature is rarely used and will likely be removed in the next major release of GSAP in order to streamline things.

 

I'm curious - what's helpful to you about useFrames:true? I always like to understand the value because perhaps we shouldn't drop it in the future. I almost never see anyone use that feature. 

 

Again, sorry about any confusion there. 

[mattkahl]

I'm new to GreenSock. So I'll say upfront that I may have misconceptions based in ignorance.

 

That being said, my primary exploration with the tool right now (2 days in) is with the following use-case:

I have an animation that was created using a different frame-based tool. I'm currently manually translating that animation in code (as preparation to automate it in the future) with GSAP + PixiJS. Having a frame-based source (30 fps, FWIW) makes features like `useFrames` very appealing because it's a 1-to-1 transcription when creating Timelines and Tweens.

 

Is that a compelling use case? Any tips for me?

[GreenSock]

One workaround is to pause the useFrames:true timeline, set globalSync:false on the GSDevTools instance, and specify that timeline as the animation like this: 

See the Pen befb2a7f1fe499c194f8923edaad7181 by GreenSock (@GreenSock) on CodePen

 

Then at least you can use the scrubber properly.

 

As for your task of porting a frames-based animation in, there are a bunch of ways you could approach that actually (without useFrames:true). For example, build it as if 1 second = 1 frame (just to make the numbers easy) and then adjust the timeScale() to 30 to make it play at that rate. In other words, put all your animations in a timeline instance and alter the timeScale on that timeline. 

 

Or if you've got things that must jump in whole increments (like exactly 30 discrete steps rather than smooth interpolation), you could actually use the same technique as above, but then pause() the timeline and animate its time using a SteppedEase so that it's literally jumping at the proper increment across that timeline's progress. 

 

The nice thing about building it in the "normal" fashion (rather than useFrames:true) is that you get resolution-independence time-wise, meaning smooth interpolation that runs at the same speed no matter what device. With frames-based animations, if there's a slowdown during complex sequences and frames are dropped, that means EVERYTHING takes longer. So a 1-second animation might actually take 2 or 3 seconds (only if it's under a lot of stress of course). With time-based animations, they'll just jump to the appropriate spot and drop frames to keep up. Generally that's a good thing. 

 

There's tons of flexibility built into the system, so hopefully it's relatively easy for you to accomplish whatever you want. Let us know if you need anything else. 

 

[OSUblake]

2 hours ago, mattkahl said:

Having a frame-based source (30 fps, FWIW) makes features like `useFrames` very appealing because it's a 1-to-1 transcription when creating Timelines and Tweens.

 

Nobody uses frames, but it's a scalar, so you can easily convert your frame values to seconds. I wouldn't recommend creating something that nobody uses or understands. And if you're using PixiJS, a lot of filters require actual time based values, so frames won't be much of use.

 

 

[mattkahl]

On 10/26/2018 at 1:00 AM, OSUblake said:

Nobody uses frames

Well, not *nobody*, right? As I said, my source (which was created with Adobe Animate) solely deals in frames.

 

On 10/26/2018 at 1:00 AM, OSUblake said:

you can easily convert your frame values to seconds

Yep. I was just trying to respond to @GreenSock's question about what seemed appealing to me about `useFrames`. FWIW, I've found there are some contexts in which the seemingly easy math of time->frame (and vice versa) gets a monkey wrench thrown into it (e.g. Video playback in Chrome doesn't have a consistent frame duration regardless of the source. So, if you actually want to advance a video frame-by-frame, it's impossible.).

[mattkahl]

On 10/26/2018 at 12:26 AM, GreenSock said:

For example, build it as if 1 second = 1 frame (just to make the numbers easy) and then adjust the timeScale() to 30 to make it play at that rate.

Great advice!

Thanks for the tips and the added context about resolution independence. I'll give this a try.

PS - I've definitely experienced the downsides of frame-based animations (and lack of "resolution-independence") previously with TweenJS.