gmullinix Posted February 18, 2020 Share Posted February 18, 2020 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 Link to comment Share on other sites More sharing options...
ZachSaucier Posted February 18, 2020 Share Posted February 18, 2020 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)? 1 Link to comment Share on other sites More sharing options...
GreenSock Posted February 18, 2020 Share Posted February 18, 2020 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. 2 Link to comment Share on other sites More sharing options...
GreenSock Posted February 18, 2020 Share Posted February 18, 2020 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. 3 Link to comment Share on other sites More sharing options...
gmullinix Posted February 18, 2020 Author Share Posted February 18, 2020 @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? 1 Link to comment Share on other sites More sharing options...
GreenSock Posted February 18, 2020 Share Posted February 18, 2020 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? 1 Link to comment Share on other sites More sharing options...
gmullinix Posted February 18, 2020 Author Share Posted February 18, 2020 @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 2 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now