lag when using pin:true with container query

[issam.seghir]

I'm trying to add animation when scrolling with pin:true property

I expect something like this :
original website : https://www.captions.ai/

 

I am trying to recreate this animation, but I am experiencing lag issues when implementing it. Whenever I scroll to the start position, the content of the section disappears.
 

After some investigation, I realized that I had wrapped all my divs inside a container div 
 

  which initialized a container query with the propertycontainer-type: inline-size However, when I removed this line, the animation started working again.

I am not sure if GSAP doesn't work with the new container query or if I am missing something.
Can someone please explain why this is happening? 
 

I also found that setting the property "pinRearent" to true fixes this problem. However, after reading the documentation, I discovered that it has some downsides. Therefore, I would like to avoid using it if there is another solution available.

 

https://i.imgur.com/QLqWIGl.gif

See the Pen YzdeoeO by issam_seghir (@issam_seghir) on CodePen

[issam.seghir]

...

[Rodrigo]

Hi @issam.seghir and welcome to the GreenSock forums!

 

This is not a GSAP related issue, but more a CSS one.

 

It seems to me that this stems from here (taken from the MDN docs):

https://developer.mozilla.org/en-US/docs/Web/CSS/container-type#values

inline-size

Establishes a query container for dimensional queries on the inline axis of the container. Applies layout, style, and inline-size containment to the element.

So then the layout containment does this:

Note: using layout, paint, strict or content values for this property creates:

1. A new containing block (for the descendants whose position property is absolute or fixed).
2. A new stacking context.
3. A new block formatting context.

The problem is in #2. The fact that creates a new stacking block creates the problem you're seeing as mentioned here:

https://stackoverflow.com/questions/15194313/transform3d-not-working-with-position-fixed-children

 

You can use pinType: "transform" in order to fix this:

gsap.to(".ai__desc", {
  rotation: 360,
  scrollTrigger: {
    trigger: ".ai__main",
    pin: true,
    pinType: "transform",
    start: "top top",
    end: "+=2000",
    scrub: 1,
    markers: true
  }
});

Hopefully this helps.

Happy Tweening!

[issam.seghir]

using  pinType: "transform", works for the first time but when repeating scrolling this is what happen : 

https://i.imgur.com/zmB40iG.gif

[Rodrigo]

Mhh.... I don't know what to tell you. When scrolling up and down it works as expected in the codepen example:

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

 

So there has to be something else in your setup that is causing this issue.

 

Is worth noticing that you have some CSS animations in your styles, be sure that is not affecting/animating the same element(s) you  are animating with GSAP, because that will create an issue of it's own.

 

Happy Tweening!

[GreenSock]

From your screen capture, it kinda looks to me like a thread synchronization issue caused by the fact that modern browsers perform scrolling on a totally different thread that's not synced with the main JS thread. Have you tried either using ScrollTrigger.normalizeScroll(true) -OR- ScrollSmoother to ensure that the scroll-related updates are done on the main thread? 

[issam.seghir]

It happens even in CodePen. If you add a border to visualize what happens, the problem begins when you try to scroll in or out quickly. The section starts jumping, making it hard to scroll again. The section keeps jumping when you try to scroll again.

[issam.seghir]

I gave ScrollTrigger.normalizeScroll(true)    a try, but it didn't fix the problem and made the scrolling experience worse.

[GreenSock]

I cannot reproduce the issue at all in any browser. Is there a secret to reproducing the problem? Can you be very specific about the device and browser you're using? 

[issam.seghir]

i'm facing this in Edge browser Version 117.0.2045.36 (Official build) (64-bit)
and in Chrome dev version Version 118.0.5979.0 (Official Build) (64-bit)
system : windows 10 pro Version 22H2 (OS Build 19045.3448)

The problem happens even in codepen so there is no secret in my code , the same code You can review the same code on my CodePen example.

https://i.imgur.com/5wrNUOv.gif

[Rodrigo]

Hi,

 

The only thing I can think of in the way you describe this as a lag when scrolling up, is the default ease it gets applied to GSAP instance which is power1.out:

https://greensock.com/docs/v3/Eases

 

So as you can see the animation starts faster and then it slows down, that's why when going back it seems that there is a lag or delay soto speak, but that's just the easing function.

 

One alternative is to try ease: "none" in your Tween config:

gsap.to(".ai__desc", {
  rotation: 360,
  ease: "none",// no easing function
  scrollTrigger: {
    trigger: ".ai__main",
    pin: true,
    // pinSpacing: "margin",
    // pinReparent: true,
    // anticipatePin: 1,
    pinType: "transform",
    start: "top top",
    end: "+=2000",
    scrub: 1,
    markers: true
  }
});

Hopefully this helps.

Happy Tweening!

[issam.seghir]

thanks rodrigo , its better now , but I am still experiencing a problem when I use the middle button of my mouse for scrolling (when I continuously press the middle button to scroll automatically). However, regular scrolling with the mouse wheel functions properly.
 see this video , I demonstrate the difference between scrolling with the middle button pressed and using only the mouse wheel.

 

-  I think from the beginning this is  the case of jumpy lagging ( using the middle button for scrolling)
- and this problem only happen when using : pinType: "transform",

 

[GreenSock]

I don't have much time right now to look at any of this, but that certainly sounds like what I originally guessed - a syncing issue. Basically, your "wheel" events are triggering the browser's [separate] scroll thread which moves the whole page visually but then the JavaScript thread executes (separately) and corrects things (moves the pin according to the new scroll position). So you could try disallowing the native scroll, like by setting up a wheel event listener that has passive set to false, and call preventDefault() on those, opting instead to do the scrolling via JavaScript on the main thread so it's all synced up. Using something like ScrollSmoother or Lenis may basically accomplish that same thing for you.