Jump to content
GreenSock

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

avancamp

ShockinglyGreen
  • Content Count

    42
  • Joined

  • Last visited

Community Reputation

19 Newbie

About avancamp

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Chicago

Recent Profile Visitors

856 profile views
  1. Thanks @GreenSock -- any chance I could get this in npm tarball form to verify the fix in my real-world app?
  2. Hi again, here's another repro with the release build of 3.2.0. I didn't make a codepen because the starter codepen is still using 3.1.1 it seems: Things to note: If the .call is removed, then the .to plays as expected. If autoRemoveChildren is set to false, the .call is fired but the .to doesn't play. Again, commenting out the .call makes the .to play as expected. import { gsap } from './esm/index.js'; const header = document.createElement('h1'); header.textContent = 'Hello world.'; document.body.appendChild(header); let called = false; // On a timer because I'm not sure that putting this in // an onComplete does the right thing in this test case. setTimeout(report, 1000); const tl = gsap.timeline({autoRemoveChildren: true}); // Everything in here is skipped. setTimeout(() => { tl.call(() => { called = true; }); tl.to(header, { duration: 0.2, y: 100 }); }, 500); // Seems to start failing around 300ms. function report() { if (called) { console.log('Success!'); } else { console.log('Failed, callback skipped.'); } }
  3. I think I'm all set now. I just ran my test suite 10 times and had zero failures. Thank you very much for accommodating my niche use case and being so responsive.
  4. The new build does fix that case, but seems to have regressed in another area and caused this case to fail: import { gsap } from './package/index.js'; const header = document.createElement('h1'); header.textContent = 'Hello world.'; document.body.appendChild(header); let called = false; // On a timer because I'm not sure that putting this in // an onComplete does the right thing in this test case. setTimeout(report, 1000); const tl = gsap.timeline(); // Everything in here is skipped. setTimeout(() => { tl.to(header, { duration: 0.2, x: 100 }); tl.call(() => { called = true; }); }, 100); function report() { if (called) { console.log('Success!'); } else { console.log('Failed, callback skipped.'); } }
  5. One more edge case, I think this may be the last one: import { gsap } from './package/index.js'; const header = document.createElement('h1'); header.textContent = 'Hello world.'; document.body.appendChild(header); let called = false; // On a timer because I'm not sure that putting this in // an onComplete does the right thing in this test case. setTimeout(report, 1000); const parent = gsap.timeline({ autoRemoveChildren: true }); parent.add(makeChildA()); parent.progress(1); setTimeout(() => { parent.add(makeChildB()); parent.progress(1); }, 100); function makeChildA() { const tl = gsap.timeline(); tl.to(header, 0.2, { x: 0, y: 150 }); return tl; } function makeChildB() { const tl = gsap.timeline(); tl.to(header, 0.2, { x: 150, y: 0 }); tl.call(() => { called = true; }); return tl; } function report() { if (called) { console.log('Success!'); } else { console.log('Failed, callback skipped.'); } }
  6. I think it might be fixed! I can't get the issue to repro on my real-world app anymore. I'll keep banging on it and report back if I manage to find any more issues.
  7. Okay, here's an actual repro that makes sense and won't waste your time lol: import { gsap } from './package/index.js'; const header = document.createElement('h1'); header.textContent = 'Hello world.'; document.body.appendChild(header); let called = false; // On a timer because I'm not sure that putting this in // an onComplete does the right thing in this test case. setTimeout(report, 1000); const parent = gsap.timeline(); parent.add(makeChild()); // Yes, this being delayed is part of the repro. requestAnimationFrame(() => { parent.progress(1); }); function makeChild() { const tl = gsap.timeline(); tl.call(async () => { tl.pause(); await waitForImageToLoad(); tl.resume(); }); console.log('Creating grandchild timeline and adding it to the child timeline...'); // This entire grandchild timeline is skipped. tl.add(makeGrandChild()); return tl; } function makeGrandChild() { const tl = gsap.timeline(); tl.to(header, { duration: 0.2, rotation: 15, x: 100, y: 150 }); tl.call(() => { called = true; }); return tl; } function waitForImageToLoad() { return new Promise(resolve => { setTimeout(() => { resolve(); }, 300); }); } function report() { if (called) { console.log('Success!'); } else { console.log('Failed, callback skipped.'); } }
  8. Haha, it comes from having used GSAP for about 6 years and having written many tens of thousands of lines of animation code with it. At this point I have a massive library of really complex graphics I can fire up which, for better or worse, strain parts of GSAP in ways they are perhaps not intended to be strained. I have unfortunately found another repro, this one doesn't necessarily involve progress or timeScale either: EDIT: Gosh I'm a fool, this repro makes no sense and will always fail lmao. Sorry, let me go try again...
  9. The issue has changed, but I don't think it is fixed. Here's another repro which adds autoRemoveChildren and re-orders the tweens/calls, and gets the issue to happen again. Of note is that if the final tween is commented out, the test passes. Very strange: import { gsap } from './package/index.js'; const header = document.createElement('h1'); header.textContent = 'Hello world.'; document.body.appendChild(header); let called = false; const timeline = gsap.timeline({ autoRemoveChildren: true, onComplete() { report(); } }); timeline.call(async () => { timeline.pause(); await waitForImageToLoad(); timeline.resume(); }); timeline.call(() => { called = true; }); timeline.to(header, { x: 300, duration: 1 }); // When this tween is commented out, the test passes. timeline.to(header, { y: 100, duration: 1 }); timeline.progress(1); function waitForImageToLoad() { return new Promise(resolve => { setTimeout(() => { resolve(); }, 300); }); } function report() { if (called) { console.log('Success!'); } else { console.log('Failed, callback skipped.'); } }
  10. @GreenSock Thanks, I'll give it a whirl tomorrow morning and report back. Also, if this edge case is just too strange to accommodate, I would accept something that prints a warning to the console advising against this behavior if GSAP detects this sort of thing. I don't mind changing my code, as long as I can't accidentally walk into this footgun again. And yeah, broadcast graphics are super weird and require all kinds of weird uses of tooling haha. There's so many things I do that must seem absurd when viewed from a normal web dev perspective. For example, I have graphics that ideally need to run for 7 full days straight. That's a very long-lived timeline, which is constantly reacting to events and queuing up animations. I also need to have systems which can immediately advance any animation to its end state, so that an operator can preview what the graphic will look like before they air it live. Stuff like that.
  11. Okay, that latest beta fixed all the new issues, thanks for that. I am now back on my original issue: .call being skipped. I believe I have found a minimal repro. The problem is indeed caused by pause/resume. I believe the issue is that when progress(1) and/or timeScale(99) are used, increasingly large parts of the timeline are considered to be "under the playhead" in a given tick, and therefore more and more things get skipped when resume is invoked, due to it always setting suppressEvents = true. This is a 3.1.1 CodePen, but the issue appears to be the same on 3.2.0-beta. Look at the console output to see if the test passed or failed: EDIT: Also, if autoRemoveChildren: true is added to the timeline, it appears that onComplete gets called twice? https://codepen.io/Lange/pen/xxGwOqY?editors=0010
  12. It may be rare in other codebases, but it is used heavily in mine haha. For whatever reason, it's a pattern I've found myself using extensively. Thanks for updating the build, will report back once I test it. EDIT: Well, not "for whatever reason", the reason is that GSAP timelines are a great tool for creating long-running sequential queues of things, so I often have these timelines that live for the lifespan of the page which get things added to them when various events fire.
  13. Got it, here's an even more minimal repro. The issue seems to occur when a timeline is created, but doesn't have any children added to it for a while. import { gsap } from './package/index.js'; const header = document.createElement('h1'); header.textContent = 'Hello world.'; document.body.appendChild(header); const timeline = gsap.timeline(); console.log('parent immediately after construction', timeline.parent); // This delayed anim never plays. setTimeout(() => { timeline.to(header, { x: 300, duration: 1 }); console.log('parent 1.5s later', timeline.parent); }, 1500);
  14. Very interesting -- this new build fixes this bug for that minimal repro, but not for my real-world app, so there is some other condition under which this same bug (timeline not playing, parent being null unexpectedly) may happen. I'll keep trying to find another repro.
×