Jump to content
GreenSock

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

ZachSaucier last won the day on September 24

ZachSaucier had the most liked content!

ZachSaucier

Administrators
  • Content Count

    5,135
  • Joined

  • Last visited

  • Days Won

    131

ZachSaucier last won the day on September 24

ZachSaucier had the most liked content!

Community Reputation

4,897 Superhero

About ZachSaucier

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    USA
  • Interests
    Frontend development, soccer, board games, theology

Recent Profile Visitors

6,279 profile views
  1. I recommend hiding overflow on the .screen element like I said and then translating the content within it (instead of the .screen element itself like you are currently doing). That way you can work around the rendering bug.
  2. The issue is that you first have a .from() tween which sets ".animated-header" to 0 when it initialized. Then you have a .to() tween when animates from the current opacity value of 0 to a value of 0. Hence it visually jumps. That's actually one of the most common GSAP mistakes. To fix it, just use a .fromTo() instead. hardwareTimeLine .fromTo(".animated-header", { autoAlpha: 1 }, { autoAlpha: 0 }) Side notes: Please use the "fork" button on CodePen when making new versions so that context is retained for future readers of the forum. I recommend using the built in formatter so your code is more readable. It's best to avoid inline styles in your HTML.
  3. Hey Mitchell and welcome to the GreenSock forums and the wonderful world of GSAP! As with most things, there's multiple ways to approach this situation. I'd probably use a very different approach where you loop through each word and create a different set of animations for each. One tween for the translation and one tween for the ease for each word. Then add those animations to the same timeline so that they're sequenced. I'd likely also use GSAP's SlowMo ease which is great for easing both of those tweens (see what it looks like using GSAP's ease visualizer). Something like this: https://codepen.io/GreenSock/pen/yLOrRMJ?editors=0010
  4. You should create ScrollTriggers in the order that they are needed in or user refreshPriority to order them property. In this case that's a little tricky because you have pinned elements surrounding non-pinned ScrollTriggers. Perhaps it'd be easiest to use a data-attribute to set the refreshPriority of elements? Simply moving the contentSelector.forEach((element) => { code to the end helps.
  5. GSAP's ScrambleText plugin is perfect for this!
  6. That's not the way to go about doing something like that. What you could do change one or more of the following: The transformOrigin of your element so it scales down to a different location in your viewport. Pin a different part of your container. Add a translation along with your scaling. This is 100% a Chrome rendering bug. Looks like something is being rounded incorrectly. Apply overflow-x: hidden; to your .screen to hide it. It actually works properly. But your animation is so fast it's hard to catch. It might be better to change the start position to something like "center 80%" to have it be on screen more. Don't use a scrub. Use toggleActions. You'll have to be more specific, I don't know what you're talking about. In general it's best to try to stick to one question per thread when possible. Asking us to debug several aspects of a project like this make it harder for us to help and in most cases you'll actually figure out the issue yourself when you try to make a more minimal demo
  7. ZachSaucier

    Text rotator

    @heyitsA I can see what you're showing now. It's a bug in the latest beta version of GSAP. Just switch out for the latest live version (3.5.1) and it will work fine. We'll get the beta fixed as well
  8. Hey breck421 and welcome to the GreenSock forums. The best thing you could do to help improve the performance of this is to buy a top of the line CPU and GPU What you're trying to do is process intensive, period. As for code changes, you'll probably get better performance by using modern image formats (like webp) that have a smaller file size. Using smaller dimensions and scaling up will probably help if that's acceptable. Only animating one image at a time (especially preventing animations on ones off-screen) will help. Using will-change will also help. All in all it's 100% not a GSAP issue and there's not really anything that we can add here that's not already on the web about improving performance
  9. You're targeting all of your boxes in the timeline and applying that same timeline to each ScrollTrigger. What you should do instead is create a timeline for each section and make the target just the boxes in that section. I talk more extensively about how to do that in my article about animating efficiently and also the common GSAP mistakes article.
  10. I would just wait to create the ScrollTriggers until the loader animation is complete. You can use the onComplete callback of the loader tween to do that.
  11. Perhaps you're initializing ScrollTrigger before the images have been loaded? If so you could Wait to initialize ScrollTrigger until all of the image have loaded or Refresh ScrollTrigger once the images have loaded or Give the images width and heights so that they take up the amount of space they will take so that they're sized correctly before they load.
  12. Sorry, it's impossible for us to debug an issue that doesn't exist in the files that you provide. Let us know if you're able to recreate it in an Angular project that you can put on CodeSandbox.
  13. Hey Clemeeent and welcome to the GreenSock forums. I'm not really understanding your end goal. Is something wrong with the demo that you posted? Or are you just looking for improvements to your code? In case you haven't seen them already, there are several horizontal scroll sections in the ScrollTrigger docs. There's also thread thread which is very related. I think that reading through them you'll get what you need? If not, please let us know what you can't figure out
  14. Hey jedifunk. It's really hard for us to debug a live site like this. Please make a minimal demo of the issue (we don't need to see your assets or the majority of your code) if you'd like our help debugging:
  15. I don't think the TS declaration files are in that beta. They will be in the public release.
×