yak

^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. Here's the updated, working demo. Thanks so much Jack! Your insights finally brough my torture to an end. I owe you a beer or something.

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. /infodump

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.