Scroll animation on one scroll

[Rohit Pathak]

Hello, I'm new to GSAP and I'm trying some handy animation. Here  is what I'm trying to achieve https://genevoism.com/. I know they have used different approach but I belief such animation are possible in GSAP too. I using combination of ScrollTrigger, ScrollTo, Observer and using timeline pause and play method to achieve one scroll animation effect. By one scroll I mean that each of animation would be trigger per scroll.

 

Approach I took :

> Firstly I have made different timeline for different animation per section. 
> Than I tried to get user scroll using observer's onUp and onDown methods.
> Than after per scroll I play my desired timeline and as one of the tween of that timeline gets completed I pause my timeline, further when user will scroll again timeline play's and pause's again.
> When all tweens in one timeline gets completed, I switch to other timeline by pausing the first one.

> I have also used a forEach loop on scroollTrigger.create so that I can pin the particular section as animation are being performed.

What I want:
I want set of animation such that when my section comes in viewport or is already present in viewport( like hero or banner ) the animation should get started as the user scroll. Each and every animation or tween should start and end between two scroll of user. And as all the animation in a section get's completed it should slide up or down as per user's scroll 100% or 100vh.

Please have a look into the below pen and guide me where I'm going wrong.

Thank you...

<script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

 

See the Pen dyLQYvb by yetnagtr-the-bold (@yetnagtr-the-bold) on CodePen

Edited April 19 by Rohit Pathak

[Rodrigo]

Hi @Rohit Pathak and welcome to the GSAP Forums!

 

Mixing ScrollTrigger with Observer is a bit more complicated than just use the Observer Plugin. If I was you I'd try to solve everything just with the Observer Plugin alone (like the website you linked).

 

I think most of your problems could stem from this:

onUp: () => {
  if (timeLine1.totalProgress() < 1) {
    timeLine1.play();
    console.log(timeLine1.totalProgress());
  } else if (timeLine1.totalProgress() == 1 && timeLine2.totalProgress() < 1) {
    timeLine2.play();
    console.log(timeLine2.totalProgress());
  } else if (timeLine2.totalProgress() == 1 && timeLine3.totalProgress() < 1) {
    timeLine3.play();
    console.log(timeLine3.totalProgress());
  }
},

Now I wouldn't use that approach at all. What I would do is to track the amount of steps each timeline has and if the amount of taken steps of a particular section are completed (4 out of 4, if a section requires 4 wheel events to complete a timeline for example) just move onto the next section. I would approach this as a user controlled content slider where each slide has some specific internal animations that should complete (in any direction) before going to the next/previous slide (if any of course). Also instead of checking for progress I would just use a simple boolean that should be toggled to true when the user scrolls and toggle it back to false after that particular section is completed, in order to use that as something that prevents the user from keep scrolling and perhaps triggering the animations of other sections.

 

Right now I don't have the time to dig into this and create a minimal demo for you that illustrates the approach I described above, but hopefully this gives you an approximate idea of what I think should be the best course of action for something like this.

 

Hopefully this helps.

Happy Tweening!

[Rohit Pathak]

Hello @Rodrigo 
I followed your advice and just used Observer for my problem and guess what, I got a better output than earlier but still didn't get what you were trying to explain about using booleans. Than too please check the my codepen code if there is possibility that it can be improved upto GSAP standards, than please let me know.

 

Secondly,

I have added a section for horizontal scrolling as the page's last section. And this horizontal section seems to create a jerk on sliding. I don't know why that same jerk is not visible in codepen but it's there in my project. Even though they both share the same code base. I'm attaching a video link for that VodaMedia Demo – VodaMedia - Google Chrome 2024-04-22 16-41-54 (jumpshare.com).

 

This is my updated codepen. 

See the Pen VwNqmdB by yetnagtr-the-bold (@yetnagtr-the-bold) on CodePen

<script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

[Rodrigo]

Hi,

 

Sorry to hear about the issues but unfortunately if we can't see it on the demo there is not a lot we can do. That also means that there is something else in your setup that could be interfering with this.

 

A lot of performance problems are down to how browsers and graphics rendering work. It's very difficult to troubleshoot blind and performance is a DEEP topic, but here are some tips: 

1. Try setting will-change: transform on the CSS of your moving elements. 
2. Make sure you're animating transforms (like x, y) instead of layout-affecting properties like top/left. 
3. Definitely avoid using CSS filters or things like blend modes. Those are crazy expensive for browsers to render.
4. Be very careful about using loading="lazy" on images because it forces the browser to load, process, rasterize and render images WHILE you're scrolling which is not good for performance. 
5. Make sure you're not doing things on scroll that'd actually change/animate the size of the page itself (like animating the height property of an element in the document flow)
6. Minimize the area of change. Imagine drawing a rectangle around the total area that pixels change on each tick - the bigger that rectangle, the harder it is on the browser to render. Again, this has nothing to do with GSAP - it's purely about graphics rendering in the browser. So be strategic about how you build your animations and try to keep the areas of change as small as you can.
7. If you're animating individual parts of SVG graphics, that can be expensive for the browser to render. SVGs have to fabricate every pixel dynamically using math. If it's a static SVG that you're just moving around (the whole thing), that's fine - the browser can rasterize it and just shove those pixels around...but if the guts of an SVG is changing, that's a very different story. 
8. data-lag is a rather expensive effect, FYI. Of course we optimize it as much as possible but the very nature of it is highly dynamic and requires a certain amount of processing to handle correctly.
9. I'd recommend strategically disabling certain effects/animations and then reload it on your laptop and just see what difference it makes (if any). 
10. Check if you have any CSS transitions to any of the elements you're animating with GSAP.

Ultimately there's no silver bullet, like "enable this one property and magically make a super complex, graphics-heavy site run perfectly smoothly even on 8 year old phones" 

I hope this helps!