Jump to content


elements sometimes disappear mid-transition in Chrome

Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Chrome isn't very happy with my transition-rich page. When the site is rendered in a large window (>= 1080p maximized) and transitions are initiated, one or more elements temporarily disappear.


DEMO (this is early-dev -- layout is far from complete, so please ignore the scaffolding)


I've been poring over stackOverflow and the like for possible solutions, but I've yet to run across anyone with this issue.


Any clues would be greatly appreciated.

Link to comment
Share on other sites

Hi, I don't really understand what I'm looking for in terms of 'disappearing' elements. The effect is rather intense with all of that aliasing, and I have no idea what's supposed to be there, whats missing, etc. If you could tell us exactly which element/s we should look at (IDs would help), and provide a screenshot of the correct output vs the 'bugged' version that would be a good start.


Also please consider setting something up in codepen (or online editor of your choice) so we can kick the tyres a little bit. Your unmodifiable site with minified javascript makes things a bit harder for us to diagnose.

  • Like 3
Link to comment
Share on other sites

Thanks for responding Jamie. I thought the problem would leap right out, but allow me to expand on the details since it sounds like you guys might be having trouble reproducing it.


With this demo build, the element that always disappears on my machine (when browser is maximized on a 1080p monitor) is div#scene-up>div.stars. (it's the big image with colorful stripes)


There doesn't seem to be anything unique about this element that's causing the problem. If you delete it in the console, you might notice that Chrome haphazardly picks some other element to screw up, and it will always be inside div#scene-up rather than div#scene-down. The faster you cycle through all three slides, the more elements Chrome tends to drop.


Here's an example of desired the mid-transition rendering. It's incomplete - ignore ugliness.


And here's a depiction of the problematic mid-transition rendering.


I would post this code on codepen or something, but the problem would be unreproducable since the preview window is so small. I know it's not ideal, but at least my demo can be manipulated in the console. The GSAP code is inside action.js, which is not minified.


If you're wondering where I'm going with this, here's an old non-GSAP build of my site (sans content) that roughly demonstrates what I'm aiming for. This build has essentially the same transition issue in Chrome.
Backstory: I completed and launched the first version of this page last summer. This was a non-GSAP build. I optimized it to the point that it ran fine on mobile and low-end devices, across modern browsers. The rendering problem first appeared some time around December or January after Chrome auto-updated. I've been busy with other projects since, but finally started poking around with it a few weeks back. After brute-forcing a million different potential solutions, I finally decided I'd try rebuilding the thing in GSAP. This seemed to be working at first, but now that I've added more layers the problem is re-emerging.
So this isn't just a GSAP problem - it's something core to Chrome's handling of many simultaneous transitions. I'm posting about it here because 1) this problem might be coming up for others building flashy sites in GSAP, and 2) because I figure you guys probably know far more about Chrome's rendering pipeline than most developers. I've yet to come across anyone on r/webDev or StackExchange who knows what I'm talking about.
Maybe I've simply reached the ceiling for what Chrome's current engine is capable of. But given how flawlessly it ran even heavier builds before the update, and the fact that IE, firefox, and Opera outperform it by leaps and bounds, I suspect there has to be a workaround.
Link to comment
Share on other sites

I have never heard of things simply disappearing in Chrome, but I wonder if you've tried removing the force3D:true stuff so that the elements don't get their own compositor layer. The theory would be that perhaps your GPU is running out of memory because you're throwing so much at it. Remember, adding force3D:true typically forces the browser to place that element into its own compositor layer which usually gives you better animation performance, but it's not wise to put EVERYTHING on its own layer because there are memory limits (this has nothing to do with GSAP - it's just a browser/GPU thing). The limits would be different for each device/browser. 


Also, Chrome is known for having crazy-long rendering times for resized images. So imagine you've got a 1000x1000 image and you set its width in css to be 400x400 - it must figure out how to scrunch all those pixels and apply antialiasing. Firefox seems to use a faster algorithm which ends up looking a bit more chunky (less smooth antialiasing), but Chrome prioritizes smoothness of the pixels which seems to take MUCH longer to process. So try to limit the resizing you ask Chrome to do for you. You could also try reducing the resolution of the native images/textures so that they take up less memory at runtime (thus less GPU memory and less pixels to crunch on resizes). 


I hope that helps. 

Link to comment
Share on other sites

I wonder if you've tried removing the force3D:true stuff so that the elements don't get their own compositor layer.


^Someone give this man a raise! I tried turning off force3D:true for layers that performed fine without GPU acceleration, and the disappearing layer problem vanished.
On the flip side, this fix introduced a side effect that took me off guard.
Now that I had set div.stars to be the only GPU-accelerated layer, it was inexplicably being rendered in front of all other elements.
After some digging, I learned that transforming elements removes them from the normal stack, effectively giving them a higher z-index than non-transformed elements. In case any readers aren't aware, I should mention that the force3D property works by transforming elements (transform: translate3d(0px, 0px, 0px)).
So, fixing the layer order was as simple as giving stars a negative z-index.
Thanks so much Jack! Your insights finally brough my torture to an end. I owe you a beer or something.
  • Like 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.