Jump to content
Search Community

Bug report: animated element with clip-path property that is using viewport units doesn't resize correctly

LeonGeldsch test
Moderator Tag

Go to solution Solved by GreenSock,

Recommended Posts

Hello Greensock team,

 

I want to report a bug where an element that gets animated and has the clip-path property set to a value containing a viewport unit (vw in this case), gets that value translated into pixel and set as an inline style, overwriting the original style (I don't know why that is necessary but I'm sure there's some reasoning behind this behavior). By itself there is no problem with that but if I resize my screen now (try changing the width of the window in the demo), the size of the circle doesn't change anymore since it's radius got converted from vw to px.

 

Is there any way you could fix this?

 

Thank you for your time

Leon

 

See the Pen LYreVgB by leongeldsch (@leongeldsch) on CodePen

Link to comment
Share on other sites

That's actually not a bug. GSAP has to get the computed value from the browser, and the browser almost always reports it in px. There's no way for GSAP to know that you wanted the original/starting value to be in a different unit. See for yourself: 

let dot = document.querySelector("#picture-dot");
console.log("starting value:", window.getComputedStyle(dot).clipPath);

Result:

"circle(213.9px at 75% calc(25% + 213.9px))"

To work around this, you can use a .fromTo() tween so that you can specify both the starting and ending values: 

See the Pen LYrQbdO?editors=0010 by GreenSock (@GreenSock) on CodePen

 

Does that clear things up?

 

By the way, thanks for the lovely minimal demo! Super helpful.

  • Like 2
Link to comment
Share on other sites

That makes sense! I wasn't aware the browser always gives back px.

I changed my pen a bit in the meantime to make the revealed image be static and not get pinned together with the cutout. To achieve that I changed the animation from animating the Y value to directly animating the clip-path property.
Sadly now there's another bug/unintended side effect happening and I can't quite figure out why.

The problem is that when you resize the screen during the scroll animation the animation will jump directly to it's endpoint and only jump back to it's correct position once you start scrolling again.

Any idea why this is happening/ how to fix this?

 

Here's the pen

 

See the Pen NWzyyLZ by leongeldsch (@leongeldsch) on CodePen

Link to comment
Share on other sites

  • 4 weeks later...
  • Solution

Sorry this went unanswered for so long! The issue is that you've got two tweens that are affecting the same property of the same object, both with a scrub. That's not bad/wrong, but the thing is that ScrollTrigger must refresh from top-to-bottom in order to ensure everything is set up properly with pinning, etc. (a pinned element higher on the page would affect the start/end of elements lower on the page). So in your case, when a refresh happens (on resize), it renders that last tween last which of course makes sense, but its starting values are VERY different than the previous tween. So it's like setting that final tween's progress to 0 last. 

 

So you've got a very unusual edge case where you need to go back and force a render of a previous tween if it's active (scroll position between its start and end). You could do that with a "refresh" listener: 

ScrollTrigger.addEventListener("refresh", () => {
  ScrollTrigger.getAll().forEach(t => t.isActive && t.animation.render(t.animation.time(), true, true))
});

That seems to resolve it in your demo. 

 

I hope that helps. 

  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...