Parallax bug with chrome (jumping content)

[Elodie]

 

Hello,

 

I have a problem  with animation applied to SVG path on Chrome.

It makes the sections of my page "jump", it's really visible in the two parallax (space issue with the pin sections ?)

> you can see a screen of my bug here : http://ukubi.fr/test/proto/bug.png

 

Here is my code, you can delete the animation at the beginning of the CSS file to see the difference (#plantTop path). I try also to make the animation with Gsap but I have the same bug (comment in the script.js). I see the bug only when I add an animation of a path, no problem with others animations.

https://codesandbox.io/s/agitated-wing-dnoyk?file=/style.css

 

Can you help me to understand  ? Something wrong with my code ? Thanks !

 

[ZachSaucier]

Hey Elodie and welcome to the GreenSock forums. 

 

You've discovered exactly why we can't just use transforms for pinning. Browsers usually handle scrolling in a completely separate thread than the main JS thread. So it's impossible to keep things synced on scroll solely using JS. That's why for pinning in ScrollTrigger transforms alone are not sufficient (we have to change the DOM some and use fixed positioning). 

 

Your pen also reminds me of this demo listed in the ScrollTrigger demos section. Perhaps it can help instruct you:

See the Pen OJyPmgX by GreenSock (@GreenSock) on CodePen

 

Additionally I noticed that you're using some of the old GSAP syntax. We recommend the sleeker newer syntax:

 

If you'd like additional help, I think it'd be wise to create a more minimal demo, stripping out everything unrelated to the issue at hand 

[Elodie]

Hello, thanks for your answer and the link very useful.

So I make some tests and I create a minimal code, finally I don't think it's a pin/ svg issue.

I declared a simple infinite animation on a title H1 and the parallax timeline. I still have this page break bug on Chrome (when I refresh or leave the page, it randomly reappears, jumping content).

It does not appear at all in two cases: if I remove the animation OR if I remove the background image in the css file (?? the image is 250 ko not so big). I don't understand this bug (a problem with loading, GPU?).

 

To test (leave the page and come back) : https://pwlfu.csb.app/

Code : https://codesandbox.io/s/epic-glade-pwlfu?file=/script.js

 

> I use the parallax demo and make it more responsive

> I don't really understand  this part "why we can't just use transforms for pinning" (sorry true newbie !)

> I find this, is it a similar issue ? (Why does my "scrub" animation jump on initial load ) : scrub parallax jump at the start ?

 

Thanks again for your help ^ ^ !

 

[GreenSock]

If I understand your question correctly, Zach is right - this isn't related to GSAP at all, it's due to the fact that modern browsers handle scrolling on a different thread. So let's say you've got a relatively challenging scene for the browser to render (SVGs are inherently CPU-intensive to render because every pixel must get fabricated from vectors), and you scroll the content really fast. Let's just talk about one update - think of it like the browser takes a screenshot of the entire page as it is currently rendered, and moves all of the pixels up for the scroll (except position: fixed stuff which shouldn't scroll). Imagine what that would look like in your scenario since you're handling the movement of the parallax/background stuff manually (position: fixed and then using GSAP to shift it). Therefore, on the scrolling thread, the browser renders that WITHOUT any of the background parallax movement initially and then on another thread it runs those updates. THAT is why you're seeing the breaking apart - it's the time between when the scrolling thread renders the page and when the JavaScript thread runs and repositions the parallax stuff. 

 

Normally you don't see it because the browser is so fast, but if you've got something that's chewing up resources like an animation going back and forth, it bogs things down. And in most cases, 99%+ of the CPU load is graphics rendering whereas a tiny portion is actually GSAP updating the values. So this isn't a matter of GSAP slowing things down - it's the nature of the browser having to render all those pixels in new places. The more areas of the screen that must get repainted, the more you're bogging down the browser. 

 

If you need those two things to stay synchronized during scroll, I'd strongly recommend NOT building your project such that some of the elements are moving with normal scroll, and others are moving via JavaScript (or CSS). You could, for example, have everything scroll in the normal flow of the document, but adjust things dynamically with GSAP. Or you could fake the scrolling by using a smooth scrolling library, for example, so that everything is done on the JavaScript thread.

 

You could also experiment with adding will-change: transform in the CSS for elements that are animating. That won't really solve the issue, though - it just might help performance a bit. 

[ZachSaucier]

11 hours ago, Elodie said:

page break bug on Chrome (when I refresh or leave the page, it randomly reappears, jumping content).

To hide jumps like that you can follow the technique outlined here. 

[Elodie]

Thank you so much Jack and Zach ! I really appreciate this community, you gave me good leads by taking the time to explain.

So I met my new friend Locomotive Scroll and now I have a pretty smooth scroll

 

I adapt the parallax and put a pin with Gsap on each layer (no more position fixed in the css but absolute)

      //PARALLAX
      const parallax = document.querySelectorAll(".parallax");
      parallax.forEach((elem) => {
        const depth = elem.dataset.depth;
        gsap.to(elem, {
          scrollTrigger: {
            trigger: elem,
            scrub: true,
            pin: true,
            pinSpacing: false,
            start: "top top",
            scroller: ".smooth-scroll"
          },
          yPercent: -100 * depth,
          ease: "none"
        });
      });

The result of the parallax if it can help someone : https://xoiuv.csb.app/ 
This is my code I hope it's ok now with the GSAP3 syntax (I add images and animations to test perf + scrub/play/pin sections) : https://codesandbox.io/s/strange-noether-xoiuv?file=/script.js

 

> A 1px line sometimes appears between the sections (bottom of the parallax and the wave between the 2 pin sections), I fix it in the CSS with a position "top: -1px"

> No more issues with my SVG / CSS animations, I don't realize if it's an aberration to make animation in CSS with GSAP, but it works pretty well and it's just simple ( I don't have the impression that it plays a big role in performance). But if it makes a real difference, I will create them in Gsap, what do you think about ?

 

Again thank you for giving the keyword "smooth scrolling" ^ ^ it helps a lot in my research

> Demo Locomotive Scroll + Gsap : 

See the Pen ExPdqKy by GreenSock (@GreenSock) on CodePen

> Newbie Tuto : 

 

[GreenSock]

45 minutes ago, Elodie said:

> No more issues with my SVG / CSS animations, I don't realize if it's an aberration to make animation in CSS with GSAP, but it works pretty well and it's just simple ( I don't have the impression that it plays a big role in performance). But if it makes a real difference, I will create them in Gsap, what do you think about ?

 

If it works for you, great. Here are some reasons to do them in GSAP (but it's not "wrong" not to):

1. If you ever need to animate that same element with GSAP, it's a very bad idea to use CSS for some animations, and GSAP for others. We explain why here. You'll get better performance and accuracy sticking with GSAP. 
2. CSS can be extremely cumbersome to build animations in. For very simple things, it's okay, but as soon as you start getting even moderately complex, it's a nightmare. So for future extendability/maintainability, you may be limiting yourself if you use CSS. I've seen people do CSS initially because it was just a simple thing...and then the client asked for 3 other changes down the road that made it much more complex and they had to rebuild the whole thing in GSAP. 
3. It's impossible to independently control each component of transforms with CSS (x, y, scale, rotation, etc. with different timings/eases)
4. Certain eases are impossible in CSS. Elastic, bounce, SlowMo, and many others.
5. Compatibility - GSAP solves cross-browser inconsistencies like if you try to rotate around an SVG element's center, for example, it won't work right in certain browsers unless you do a lot of extra work in CSS. GSAP "just works". 

But again, it isn't "wrong" to use CSS for simple stuff. If it works, great. No need to feel bad about doing it

 

Thanks for sharing your solution. Happy tweening!