avancamp

I think I see what happened -- I misunderstood the structure of this example test case and my modification does not make sense and is not an accurate representation of the real-world issue I am encountering. I will have a better explanation of my use case and issues in a few days. I am indeed not actually doing any infinite loops or using rAF in my real world code.

Hm. I'm not sure what this means for the real-world code I have which seems to experience this issue. Am I somehow using pause in a way that is unsupported?

I have to be honest, I do not understand that explanation haha. I'm very confused.

I managed to modify @GreenSock's example test code in a way which makes it intermittently fail. I did this by adding a pause and resume on every 10th run of the doCall method: https://codepen.io/Lange/pen/oNgRmmx

More clues from my investigation (I can't sleep so I'm just doing this lol): When this issue happens, the afflicted timelines will have a progress that is less than 1 when all is said and done. The afflicted timelines are not paused, but their progress still does not advance beyond whatever it gets stuck at. On every run, it seems that the progress of these afflicted timelines gets stuck at a different number. Perhaps of note is that the time value of the afflicted timelines in these scenarios always has a long decimal like 1.188000000000006, 0.7920000000000069, or 0.49500000000001165. The number changes every time I run the test. The timelines often get stuck, but where they get stuck seems to have no consistency, Is this perhaps another manifestation of this same floating point rounding issue that you fixed elsewhere in the 3.1.2 beta? Is some rounding error preventing some triggers from running that would then prevent these timelines from being fully completed? This latest round of test was indeed still done on that 3.1.2 beta build, so it alone does not appear to fix whatever problem I'm having (if it is indeed a GSAP problem and not a problem in my own code). EDIT: So to clarify, the issue isn't that .call is being skipped, it's that the timeline is being left in an unfinished state, despite not being paused. EDIT 2: I should also state that my timelines do heavy pause manipulation. By that I mean: they are often pausing themselves or their children to perform tasks with an indeterminate runtime, after which they resume themselves. But I have to stress that when this issue happens, timeline.paused() reports that the timelines are not paused anymore, but they still aren't progressing to their end.

Thanks for spending some more time looking into it, I agree that at this point it's on me to just put in the hours to find out exactly what is happening. I'll follow up in a few weeks most likely.

Another clue: the problem is inconsistent. Sometimes, there's no problems at all and everything appears as expected. Other times, it feels like almost every .call is being skipped. I don't know exactly what this clue means yet, but it is important context. EDIT: To clarify, I mean that I can change zero code and refresh the page a bunch of times, and the outcome can change.

Thanks for the reply, Jack. I tried out that 3.1.2 beta, and it unfortunately does not affect my issue. I'm about to head out of town for a week for a business trip, so it might be a while before I can come back to this and put more time into attempting to find a reduced test case. Thanks, Alex

Hi, In some scenarios, my .call instances are not being invoked when I have set the timeScale of my timeline very high (for instance, 99). However, I am as of yet completely unable to find a minimal repro for this. Everything I build in CodePen appears to work as expected. My production code which has this issue consists of many complex and deeply nested timelines, so I can only assume that the repro is somehow related to the exact construction of this complex timeline. Given how much effort it would take for me to somehow convert this actual production code into a full-on CodePen to continue experimenting, I wanted to first ask if there were any well-known gotchas that might be causing this to happen. If so, I will investigate those first. If not, well I guess I need to set aside some hours to continue hunting down a minimal repro. EDIT: This is on GSAP v3.1.1 Thanks, Alex

Sure thing, I might just open a PR. Thanks!

Hi there, I'm upgrading from GSAP 2 to GSAP 3 in a Typescript codebase. To retain strong typing and autocomplete, I actually liked having to import each ease object explicitly, as follows: import {TweenLite, Power1} from 'gsap' I would like to do the same in GSAP3. It appears that the actual library does export the ease objects, such that doing this would be supported: import gsap, {Power1} from 'gsap' However, the included typedef does not list these ease objects as part of the export. Is there a particular reason for this? Thanks!

Thanks for the reply Jack. Yes, that does make sense, but I'd still think that these tweens would get played when setting timeline.progress(1). Here's the exact order of events: I create a long-living timeline that will have new animations added on to it many times throughout the life of the page. At some point, an event is fired that causes my code to add an animation to this master timeline. But, some parameter of this event tells my code that it should immediately set timeline.progress(1) after adding this animation to the timeline, so it does that. If autoRemoveChidren is true, none of those tweens that I just added get played. It's as if they're being prematurely GC'd. I would still expect them to complete in this scenario. I was able to easily refactor this particular graphic to not need autoRemoveChildren, just want to give a heads up in case this indicates a possible bug. Thanks! Alex

Oh hm, I just set autoRemoveChidren to false on this timeline and the problem no longer occurs. Is the behavior I'm seeing intended, or is this a bug in autoRemoveChildren?

Hi there, I have a fairly complex entrance anim for a graphic that I'm working on. Sometimes, this graphic needs to immediately seek to the end (via tl.progress(1)) so that the person using it can quickly see what the final product looks like. However, it seems that some of the tweens in this timeline aren't playing when I call tl.progress(1). If I add onStart or onComplete callbacks to these tweens, they never get called. If I let the anim play at a normal speed without manually advancing its progress, the playback is as expected and all tweens play. If it helps, this same issue also starts to arise when I use tl.timeScale(10). At this speed, it starts intermittently skipping tweens. I unfortunately cannot share a codepen, as this particular project is private. I feel bad asking for help on a forum on a private project like this, but I've been unable to successfully troubleshoot this issue myself. Thanks, Alex

Script updated, should be good to go: https://github.com/SupportClass/ae-ease-to-gsap-customease BTW, I welcome feedback, feature requests, and pull requests! I think this script could become a really powerful tool for improving the workflows of people converting After Effects projects to GSAP animations.

Huh, yeah. That seems totally fix it. I'll patch my script tomorrow to account for this. Thanks!

Hi there, I have the following SVG path data that I wish to use as a CustomEase. However, I think that CustomEase might not be properly normalizing this path: M16,350C17.6667,361.8333,18.2157,421,26,421 When pasted into the Ease Visualizer, this is the result: This SVG path data was generated by my new ae-ease-to-gsap-customease script, so it's possible that my script just hasn't generated the correct SVG path data. However, it certainly looks correct, which is why I'm currently suspecting that this might be an issue in CustomEase. Thanks for your time, Alex EDIT: For additional context, here's what this curve looks like in AfterEffects: