limbo Posted August 15, 2022 Share Posted August 15, 2022 Hi, hoping someone might have run into this before... If you disable mixBlendMode on the cursor effect in Chrome, in the codepen example (full screen ideally, to put a little pressure on the CPU) the transitions are seamless. Adding it back in you'll see a massive drop in performance (scrolling up and down the page at a decent, but not excessive rate) This happens with any element that's set above any animated element with mixBlendMode set (in CSS or via GSAP) — a menu link, or logo for example. CSS3 transitions/animations aren't affected anywhere near as badly... It's only apparent in Chrome/Edge — anyone know fix or good guess at one? Perhaps a lesser used "justGetWithIt: 'letsGo'" parameter or CSS webkit hack? See the Pen yLKLrEr by liamcrean (@liamcrean) on CodePen Link to comment Share on other sites More sharing options...
GreenSock Posted August 16, 2022 Share Posted August 16, 2022 Maybe try will-change: transform in the CSS. That's basically a clue to the compositor that it better cache a rasterized version of the element/artwork. 1 Link to comment Share on other sites More sharing options...
limbo Posted August 16, 2022 Author Share Posted August 16, 2022 Thanks Jack I tried that sadly no joy. Looks like Chrome/Edge just really hate any relatively complex animation (scrolltrigger with splittext is especially bad) with any kind of mix blend mode element overlaid. In this case we wanted the logo/menu to use mix-blend-mode:difference; Also tried these which can have worked on other animation issues - usually in Safari though: will-change: transform, opacity; perspective:1000px; -webkit-backface-visibility: hidden; backface-visibility: hidden; transform: translate3d(0, 0, 0); Link to comment Share on other sites More sharing options...
GreenSock Posted August 16, 2022 Share Posted August 16, 2022 Most browsers are just terrible with filters and effects like that rendering-wise (unrelated to GSAP). What's curious to me is you said CSS transitions/animations aren't affected as much which leads me to believe that there's some flag it's triggering to make things easier on the renderer. JavaScript-based animation can be just as fast (and sometimes even faster) than CSS ones - the trick is to understand what's going on under the hood. For example, will-change: transform may be necessary in JS land to cue the browser into the fact that the element will be moving whereas if you do a CSS transition it may be able to infer that "automatically". Are you positive that you're comparing apples-to-apples with your GSAP-vs-CSS conclusion? Link to comment Share on other sites More sharing options...
GreenSock Posted August 16, 2022 Share Posted August 16, 2022 By the way, you may want to experiment with adding the will-change stuff to other elements - the ones that the moving thing will be interacting with because perhaps those are the ones slowing things down. 🤷♂️ Link to comment Share on other sites More sharing options...
limbo Posted August 17, 2022 Author Share Posted August 17, 2022 Thanks Jack. Not getting a lot of love with Chrome/Edge for any animation TBH - GSAP or not. MixBlendMode answers so many good design questions too — particularly fixed nav items on a transparent BG. Appears that this machine's CPU might also be a factor as the client see's no problems on their macs (so it's still a concern, but usually the other way round!). 1 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