How Serious Are Asynchronous Panning Issues?

[Kaekos]

Hey! 

I've only been using GSAP for a few weeks, but I already love it.

I did however - while testing an app - notice that my horizontal scroll sliders caused Firefox to throw out a warning about async panning potentially becoming an issue?

Are there any current fixes to help avoid the lags that I've noticed happening because of this? 

Or would my best bet be to write my own CSS and add some sort of timer in JS to smooth out the response/animation?

 

[OSUblake]

Welcome the forums @Kaekos

 

I've never seen that warning before in my life, so I have to wonder what you are doing to cause that. Just a quick Google search brought this up, so it's unlikely CSS is a fix.

 

https://stackoverflow.com/questions/37098306/this-site-appears-to-use-a-scroll-linked-positioning-effect-this-may-not-work

 

Do you have a minimal demo that shows the issue?

 

[Kaekos]

@OSUblake Thanks Blake!

I'll have to dig into that article after dinner! 

Since you've never ran into it before, would you happen to mainly use Chrome? If so, that is probably why.

Even the GSAP website itself has that warning - but it only appears in Firefox. If you open Firefox and go to the GSAP website, once you start scrolling down the page Firefox will give you the message.

I may be able to share a minimal demo, but if I did it would have to be after dinner. I'll watch the minimal demo video and see if I can't get one posted up. It's a Webpack project with a lot of modules and dependancies so I'm not sure if it's possible. Though it very well could be, I just have no experience with CodePen or anything like that.

[OSUblake]

7 hours ago, Kaekos said:

Since you've never ran into it before, would you happen to mainly use Chrome?

 

Yep. So I researched more into this article about what that warning means...

https://firefox-source-docs.mozilla.org/performance/scroll-linked_effects.html

 

So that warning is just Firefox detecting that some of our plugins like ScrollTrigger and ScrollToPlugin might be messing with the scroll position, but that's the whole point of the plugins. 😉

 

I understand the demos in that article and why Firefox thinks they're bad, but we put a lot of work in our plugins to get around those issues, so I wouldn't worry too much about that warning. And the next version of ScrollTrigger has a bunch of new stuff under the hood to help out with async scrolling issues in certain browsers.

 

[Kaekos]

@OSUblake Awesome! Yeah I wasn't really sure if I was going to have to provide a work-around with custom code or what. I thank you for looking further into the issue. That is something I really appreciate about GSAP. In the few weeks I've started using the software, after scouring the forums I find there's almost always an insanely helpful admin or two on each post.  Thanks Blake!

[sarthak950]

hey i build some scroll triggered animation and it works on the firefox browser but not on the cromium based browser
here is the build veresion of the website :- https://main--websitevorld.netlify.app/

 

const slidetimeline = gsap.timeline({
    scrollTrigger: {
        trigger: "body",
        start: "top top",
        end: `+=${window.innerHeight * winCount}`,
        scrub: true,
        pin: true,
    },
});
slidetimeline
    .to("#slide1", {
        maskPosition: "0% 0vh",
        // clipPath: "polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%)",
        duration: 2,
    })
    .to(".contextText1", {
        opacity: 1,
        duration: 2,
    }, "-=1.5")
    .to("#slide2", {
        maskPosition: "0% -0vh",
        // clipPath: "polyg5on(0% 0%, 100% 0%, 100% 100%, 0% 100%)",
        duration: 2,
    }, "+=1")
    .to(".contextText2", {
        opacity: 1,
        duration: 2,
    }, "-=1.5")
    .to("#slide3", {
        maskPosition: "0% -0vh",
        // clipPath: "polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%)",
        duration: 2,
    }, "+=1")
    .to(".contextText3", {
        opacity: 1,
        duration: 2,
    }, "-=1.5")
    .to("#slide4", {
        maskPosition: "0% -0vh",
        // clipPath: "polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%)",
        duration: 2,
    }, "+=1")
    .to(".contextText4", {
        opacity: 1,
        duration: 2,
        onComplete: () => {
            canSkip = true;
        },
    }, "-=1.5")
    .to("#slide5", {
        maskPosition: "0% -0vh",
        // clipPath: "polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%)",
        duration: 2,
    }, "+=1");

this is the animation in consideration

[GSAP Helper]

Hi @sarthak950

 

Sorry to hear you've run into some performance issues, but there is not a lot we can do on a live site.

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). 

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!