Using 'overflow: hidden' on ancestor container causes unexpected visual breaks in tweens

[eballeste_hero]

I'm trying to understand what the negative delay is doing for the Y based tween in this snowfall codepen. I am currently experiencing an issue that does not make any sense where my implementation, being setup almost identically to this codepen, does this weird thing where using a negative delay causes the looped Y based tween of some of the elements (not all) to start abruptly "on screen" even though it was originally set (using gsap.set) to start somewhere off screen. Removing the delay parameter of the tween unfortunately causes all of the elements to drop down at the same time but they all correctly start off screen. The negative delay is the only thing that helps the animation start with a full screen of snowflakes. 

I read in a separate post that:
"A negative repeat delay will restart it before it finishes." If true, then why does it not happen in the codepen linked where the snowflakes fall perfectly from the top to the bottom of the screen? In my tests some start above the screen but others show up abruptly on screen. This has been driving me crazy 😮‍💨, appreciate any help anyone could provide. 

See the Pen GWzzNB by serban (@serban) on CodePen

[eballeste_hero]

I made a small reproduction of my current setup, it's hard to tell but some of the elements do eventually pop in out of nowhere:

 

https://jsfiddle.net/a6uoq54e/4/show

[GreenSock]

Think of a negative delay like it's setting the startTime of the tween in the past. So delay: 2 would cause the tween to start 2 seconds in the future, whereas delay: -2 would be 2 seconds in the past, like the playhead would start 2 seconds into the tween. 

 

If you want everything to start off-screen, it sounds like you just want to use positive delays. 

 

Also, did you know GSAP has a bunch of super useful utilities like gsap.utils.random()? There's no need for you to create your own "helper.random()" function. 

 

Are you looking for something like this?: 

https://jsfiddle.net/L2nmot7v/

[eballeste_hero]

Hi! I did notice the utilities, thanks!

I do want them to go from top to bottom but I want the screen to be filled with snowflakes immediately upon page load.

I don't think my issue is related to the delay though. 

I just tried a version of the script where instead of using a delay, I create individual timelines for each element with a paused state, then I set the progress of each timeline using Math.random() and finally play it. This also fills the screen similar to what the delay was doing but I still see issues where some of the dots pop into the screen, it sucks that it's not as obvious from my jsFiddle but I do see it happening even in my fiddle if I stare long enough at it. 

I'm also attaching a video of how the popping looks. I think it might be related to the fact that it's trying to scroll down a very long container which is several times the height of the window. Could this be somehow related to my issue?

https://jsfiddle.net/duwzg2vt/2/show

[eballeste_hero]

I just inspected one of the elements and it looks like once the vertical tween reaches it's end, the element starts animating from the top, off screen, like it's supposed to, but it decides to visually pop in a little after it's on screen. Almost like if it had an opacity 0 assigned to it, I have no idea what is going on. 

https://imgur.com/a/1eIYWEa

 

 

[GreenSock]

I can't replicate that problem at all. I've refreshed at least 20 times. It sure looks like GSAP is doing exactly what it's supposed to be doing, but maybe your browser is not rendering things properly, perhaps due to some kind of video card problem on your machine? I have no idea. What browser? Does it matter how big the window is? Is there a secret to reproducing the issue? 

 

Also, I'd strongly recommend not using the super old easing syntax: 

// very old (deprecated)
ease: Sine.easeInOut

// new/better
ease: "sine.inOut"

 

[eballeste_hero]

Hi, I wish it was my browser but I've tested on Firefox/Safari/Chrome and experiencing the same issue. 

I tried making a version where you can scrub back and forth through the animation by clicking on two buttons but it's still not easy to see the problem in jsFiddle. https://jsfiddle.net/r3fokdvm/14/show

Something I did notice is that the elements that are hidden immediately show up if I mess around with any of the style properties that gsap attaches to the element.

 

 

[eballeste_hero]

@GreenSock

I found the issue, but don't know what the answer is.

It seems that the visibility of the animation breaks when adding overflow:hidden to any of the parent containers. Click on the buttons to scrub through the animation:
https://jsfiddle.net/r3fokdvm/15/show 

Clicking on Prev Frame button a couple of times after the elements are visible will correctly show the animation as they exit from the top. Is this some type of weird visual bug or am I missing something?

[eballeste_hero]

I updated the post's title because this has to be some sort of bug right? I cleaned out my last version of the jsFiddle, reduced it to the bare minimum and it still consistently shows the visual break on top. Not sure what is causing it though, there's no clipping because if you reverse the animation of the visible elements they aren't hiding.

https://jsfiddle.net/r3fokdvm/15/show 

[GreenSock]

This is definitely a browser graphics rendering bug that's totally unrelated to GSAP. Here are my findings...

1. It only happens when GPU acceleration is activated on an element, specifically whenever you've got a 3d transform (which GSAP does by default in order to maximize performance by telling the browser to leverage the GPU on that element) -OR- will-change: transform. Either one of those will cause the browser to create a new layer for that element and send it to the GPU as a texture. It's much faster for the browser to just pass transforms over to the GPU to say "apply this to that pre-rendered blob of pixels". When I disabled GPU acceleration on the elements by setting force3D: false and making sure that the CSS property will-change: transform wasn't set on the element, the problem seemed to vanish. Again, a 3D transform -OR- a will-change: transform on an element will promote the element to its own layer by the browser to get GPU acceleration. So this isn't a GSAP problem. 
2. I've noticed that browsers try to apply their own behind-the-scenes performance optimizations, specifically with layerizing things and limiting the texture size, so when you've got an element that's really big, the browser basically breaks that up into chunks. For example, if your element is 50,000 pixels tall by 2,000 pixels wide, the browser is like "woah, that's too big...we're gonna bust that up into several smaller chunks of pixels" and often the browser screws up rendering in certain edge cases. It's as if it forgets that it's supposed to repaint certain pieces when they come into view. So GSAP is doing exactly what it's supposed to do, applying transforms, updating properties, etc. but the browser just forgets to paint the pixels properly in certain edge cases with very large textures. In your case, you had the container's height set to 1200vh which is VERY large. That seemed to trigger the issue. So the browser's attempt at performance optimization is backfiring and missing repaints. 

So I set the height to 100vh (and adjusted the y value in the tweens because you were basing those on the offsetHeight) so that it's not triggering the browser to break it into several chunks/textures, and I couldn't replicate the problem anymore: 

https://jsfiddle.net/ohqn2cb1/

 

Does that clear things up? I wish there was something magical we could put into GSAP to solve this problem for you, but as far as I can tell it's impossible. It's purely a browser bug that can't be worked around in the animation engine. You've gotta just be careful how you build stuff and not make massive elements with GPU acceleration. 🤷‍♂️

[eballeste_hero]

It does clear things up, I knew I wasn't crazy 😮‍💨. Thanks for all of the details, I knew these browsers were doing something funny, it just didn't make any sense at all.

I guess I have to figure out how to get rid of the overflow:hidden rule.  It has nothing to do with the overflow rule, it's just something that happens when the container is extra tall like you said.

Again, thanks!