Jump to content
Search Community

GreenSock last won the day on February 17

GreenSock had the most liked content!

GreenSock

Administrators
  • Posts

    22,902
  • Joined

  • Last visited

  • Days Won

    805

GreenSock last won the day on February 17

GreenSock had the most liked content!

Profile Information

  • Location
    Chicago Area
  • Interests
    Volleyball, Basketball, Christian Apologetics, Motorcycling

Recent Profile Visitors

99,928 profile views

GreenSock's Achievements

  1. Yes, that's exactly correct. ✅ Good job getting it solved. 🙌
  2. No problem! Happy to assist. If you discover a great fix for the canvas thing, feel free to post back here.
  3. We really try to keep these forums focused on GSAP-specific questions. Performance is a very deep topic. Just that color effect you linked to is running 4,900 function calls on every tick, and each of those functions is calling another 4 functions. And if you're doing that on 4 canvases, well, that's a LOT of calculations. Mobile device processors are much weaker than desktop ones. There are probably much more efficient ways to do what you're attempting there, but unfortunately I don't have the time to research that and build it for you. Maybe someone else has some ideas to share. Good luck!
  4. Nah, it's very doubtful that having multiple ScrollTriggers would cause an issue. Are you absolutely positive you're using the latest version of GSAP/ScrollTrigger on the site? We can't really troubleshoot Lenis-related stuff because that's not a GreenSock product (ours is ScrollSmoother). I wonder if the jitter is due to some kind of filter effects you're using (some filters are extremely CPU-intensive for rendering which is totally unrelated to GSAP)
  5. That's because your fabricated "lag" doesn't exceed the threshold. lagSmoothing(500, 33) basically means "only apply lagSmoothing when a single tick takes MORE than 500ms". And lagSmoothing(1000, 20) would need the tick to take more than 1000ms to kick in lagSmoothing. So you can increase the numIterationsyou're passing to your startLag() method. Maybe add a 0 to the end. It also depends on the speed of the device you're running the test on. Some machines will execute that loop faster than others.
  6. Yeah, my best guess is that maybe you've got something interfering with setting the scroll position, like tailwind adding scroll-behavior: smooth(?) As @GSAP Helper said, a minimal demo that illustrates the problem will be essential to getting the problem diagnosed.
  7. Online editors like Stackblitz, CodeSandbox, etc. don't seem to unify the packages, so if the @gsap/react has a dependency on "gsap" it loads that separately and then the normal "gsap" package you're using in the project is treated as a separate thing (so 2 distinct GSAP objects). Therefore, the context that gets created inside your useGSAP() is from the gsap that's loaded with useGSAP which is DIFFERENT than the one that's creating your actual animations. This is why it's best to register the useGSAP hook as a plugin: gsap.registerPlugin(useGSAP, ScrollTrigger); (do that BEFORE you use the useGSAP() hook of course). Does that resolve things for you? Yeah, that's because if you do it inside the useGSAP and you haven't registered useGSAP already, the "gsap" that creates the context is not the same one as the gsap that's creating your tweens/ScrollTriggers, as explained above. And again, this is almost never required in a "real" project because those should unify the packages during the build process. But it's still totally fine to register the useGSAP hook in any case. In summary: Is suspect it'll solve everything for you if you just gsap.registerPlugin(useGSAP, ScrollTrigger).
  8. The only other time I've seen this is when someone loaded BOTH the ESM version of GSAP (like via an import) -AND- the UMD version (like via a <script> tag). If you can provide a minimal demo that clearly illustrates the issue, we'd be happy to take a look. You can also try importing from the /dist/ directory, like "gsap/dist/ScrollTrigger" just to see if that helps at all. Ideally, it's best to just use the regular ESM files but some frameworks like Next.js don't work by default with ESM files (though I think you can tweak your config settings to have it transpile so that you can use the ESM files)
  9. It looks like you're just creating things in a slightly funky order - you should always create your ScrollTriggers in the order they'd happen on the scroll, -OR- you can use refreshPriority to explicitly control that. In your case, you're creating an animation that uses a particular element as the trigger...and then you're creating a ScrollTrigger that PINS that very same element. The pinning affects how that element moves down the viewport and when it'd trigger start/end values. See the issue? So just re-ordering your code seems to solve it, right? https://stackblitz.com/edit/vitejs-vite-qrhvku?file=src%2FApp.jsx (or did I misunderstand?) 💚
  10. Hi @Mumm-Ra. Thanks for the suggestion - are you basically asking us to make GSDevTools "frame-based" instead of "time-based"? The problem with that is GSAP is inherently resolution-independent in terms of timing, and that's a GOOD thing. In the old days, a lot of systems were frame-based, so for example you might make an animation that linearly travels 600px between frame 10 and frame 70, so 10px per frame. Seems fine initially, but what if you run that animation at a timeScale of 0.25 (quarter-speed)? Since that animation was frame-based, it's resolution-dependent, meaning it only has 60 frames worth of motion and if we now slow the playback speed, it looks a lot more jerky. GSAP, on the other hand, is resolution-independent in terms of time, so if you timeScale(0.25), it'll adjust perfectly and the motion will be totally smooth. It's not locked to moving 10px per frame like in the frames-based animation. And remember that even if requestAnimationFrame() is supposed to run 60 times per second, sometimes it doesn't. The system could be temporarily bogged down. In a frames-based system, that would mean the entire animation would take longer to finish. For example, if the system was working really hard and the frame rate dropped to 30fps, that 60-frame animation would take 2 full seconds to complete! But with GSAP, it'd still honor the 1-second duration; it'd just move a longer distance on each frame. All that to say that I do not believe it would be a good idea to make GSDevTools frame-based. It may give the false impression that GSAP works that way. A developer might intricately build out an animation such that a particular element starts moving in exactly frame 62...but then in the real-world browser on a system that's much less powerful, it may actually end up firing on tick 41 instead because the frame rate dropped. Why do you need things to be frame-based? What is difficult for you about using time (seconds)?
  11. Yeah, a minimal demo would be super duper helpful. But this sounds like a great case for gsap.matchMedia()! https://gsap.com/docs/v3/GSAP/gsap.matchMedia() And since you're using React, definitely check out https://gsap.com/react
  12. You had a typo: // bad start: 'bottm bottom' // good start: 'bottom bottom' You also were loading the GSAP/ScrollTrigger/React files from the CDN as UMD files **AND** importing them as ES Modules which you definitely shouldn't do. That's a bunch of redundancies. You also were defining "class" attributes in JSX which is invalid - you've gotta use className. That has nothing to do with GSAP; it's a React thing. And you can round the values with snap: https://codepen.io/GreenSock/pen/abMryMW?editors=0010 Does that help?
  13. That's totally possible, but it's a bit beyond the scope of help we can provide in these free forums. The basic approach I'd personally take is to get the seamless looper helper function to create the timeline, pause it, and then create a baseline variable like "velocity" representing the speed of the playhead. Then, in a tick event handler (gsap.ticker.add(() => {...})) I'd update the timeline's playhead accordingly so that it moves at a normal pace (whatever you decide that to be). Then use an Observer to listen for scroll, pointer, and touch events such that it alters the velocity according to the deltaX/deltaY, and tween that value back to the baseline with a gsap.quickTo() so that it decelerates. So your velocity variable goes up and down based on the various events/interactions, but always goes back to the baseline. Good luck! We do offer paid consulting services if you need more assistance. You're welcome to post in the Jobs & Freelance forum too.
  14. If you don't want it to have an elastic effect on mouseleave, just change the ease on that animation. The distance it drifts, that's logic stuff - just use a different multiplier for the distance. Currently you're using 0.4, but you can change that to 0.1 or something. As for completely filling the button, that's beyond the scope of help we can provide in these free forums - we really try to keep things focused on GSAP-specific questions. Most of the things you're asking about are general logic things in the code. We do offer paid consulting services if you need that. Just reach out to us if you'd like to get details about pricing and scheduling. Or you can post in the "Jobs & Freelance" forum. Good luck!
  15. You had the scroller set incorrectly and I'm not really sure how you wanted the effect to work, but maybe this will get you going in the right direction: https://codepen.io/GreenSock/pen/KKEYKOj
×
×
  • Create New...