Bug with transforms at large screen sizes in Chrome

[gmullinix]

I'm noticing a strange issue when combining transforms and animations. Divs are being covered by other divs when they shouldn't be. However this only happens at large screen sizes, and only on Chrome and Chromium Edge.

 

It's a little bizarre to explain and hard to replicate so please bear with me.

Please view Codepen #1 at full screen and in "full page" view:

• The green boxes should always be on top of the purple square.
• At HD size (1920x1080) it displays as expected.
• However, once you view it on a 4K monitor (either simulated with device mode or on an actual monitor), the  green square on the right is covered by the purple square.

Some comments about this:

• If you add force3D: false to the tween, the bug will not happen.
• If you remove one of the transforms (either on the purple square, or on #main_wrapper), the bug will not happen.
• The square's position on the gray stage can impact whether the bug happens or not. Originally all 3 squares were positioned on the left side of the stage, and there was no bug at any screen size.
• z-index doesn't help or change anything.

 

This is where it gets weird(er). Please view Codepen #2 at full screen and in "full page" view:

See the Pen poJbdoQ by gem0303 (@gem0303) on CodePen

• I added a second set of boxes which uses a translateX CSS animation to move the blue box. The presence of the CSS animation code fixes the bug. The green squares appear on top of everything at all screen sizes.
• The CSS animation has to be a transform, though. If you do an opacity animation, the bug comes back.
• ???

 

Additional comments:

• This same bug can happen if you are doing transform animations with png images.
• Sometimes the bug can happen at a 2K screen size. But it never seems to happen at 1920px width or lower.

 

I'll probably end up reporting this to Chrome because it seems more their issue than GSAP's. However I wanted to see if anyone here had run into this issue or had any insight.

 

The only consistent workaround we've found is setting the timeline default to force3D: false. 

See the Pen abOZyPK by gem0303 (@gem0303) on CodePen

[ZachSaucier]

Hey gmullinix. This definitely seems like a browser bug of sorts related to stacking contexts or the rendering being on the GPU or not. 

 

Does adding a z-index to the green squares help? Trying z-index in other places and combinations may help.

Does adding will-change: transform to the elements being transformed help?

 

I can't recreate the error by simulating a 4K screen in Chrome on Catalina. I also can't recreate the bug when using the CSS animation and animating opacity. 

 

What OS are you using? And what are the specs for the device that you're using (especially related to your GPU)?

[GreenSock]

First of all, great job isolating things in a reduced test case! I wish everyone did that as well as you did. 

 

This is definitely unrelated to GSAP, as you said. 

 

I noticed that if I set the z-index of the #moving_A to a NEGATIVE number, it resolved things. Weird, right? Does that work for you? 

 

Browsers do some odd stuff under the hood rendering-wise. For example, sometimes they'll have a threshold of pixel dimensions that trigger a different algorithm or tiling. For example, if it goes beyond 1000px, it may bust it up into several pieces for rendering. Based on the fact that you said things resolve if you set force3D:false, it means this is most likely due to how the browser is layerizing things to feed to the GPU. 

 

I'd certainly recommend filing a bug report with Webkit but I wouldn't even mention GSAP because that may be a red herring for them. I mean it's fine if you want to mention GSAP but I worry they'll be quick to think "oh, that must be a GSAP problem, go talk to them" when obviously it's not a GSAP issue. 

[GreenSock]

Also, per @ZachSaucier's suggestion, it does seem to resolve things if you force the green DIVs to their own GPU layer by doing any of the following: 

• Set force3D:true on the green DIVs
• Set will-change: transform on the green DIVs
• Set a 3D transform on the green DIVs (like a non-zero "z", "rotationX", or "rotationY")

So from what I can tell, the issue is due to how Chrome is rendering a mix of layerized and non-layerized elements. If you get them all layerized (or all non-layerized), it renders correctly. 

[gmullinix]

@ZachSaucier

 

Thanks for the link to info on the stacking context. The green squares already had a z-index (value of 70), and that was not changing anything. I added a z-index of 10 to the purple square and that didn't change it either. will-change: transform on the purple square didn't change anything.

Here's some system specs for my desktop:

OS Name    Microsoft Windows 10 Home
Version    10.0.18363 Build 18363
System Manufacturer    Gigabyte Technology Co., Ltd.
System Type    x64-based PC
Processor    Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, 3201 Mhz, 4 Core(s), 4 Logical Processor(s)
BaseBoard Manufacturer    Gigabyte Technology Co., Ltd.
Installed Physical Memory (RAM)    16.0 GB
Total Physical Memory    16.0 GB
Available Physical Memory    10.3 GB
 

My coworkers were able to see the bug. Some of them have similar desktops and some don't (laptops, different manufacturers, etc). We are all running Windows 10.

 

 

@GreenSock

 

Can confirm that a negative z-index on the purple square fixed the issue. I also figured out that backface-visibility: hidden on the green squares fixes the issue too.

When making the bug report, I wanted to link to a Codepen like I did here to help illustrate the problem. However, I'm not sure how to re-create it without Greensock. As demonstrated in the second Codepen, CSS animation doesn't appear to break. Any ideas?

[GreenSock]

39 minutes ago, gmullinix said:

When making the bug report, I wanted to link to a Codepen like I did here to help illustrate the problem. However, I'm not sure how to re-create it without Greensock. As demonstrated in the second Codepen, CSS animation doesn't appear to break. Any ideas?

Sure, just do something like this: 

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

 

No GSAP, still the same issue. Right? 

[gmullinix]

@GreenSock

 

Perfect, thank you for providing that! I will report to Chromium tomorrow.

 

edit: reported here https://bugs.chromium.org/p/chromium/issues/detail?id=1054433