Jump to content
Search Community

GSAP mixBlendMode + Chrome/Edge = v.low framerate on all animation

limbo test
Moderator Tag

Recommended Posts

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

  • limbo changed the title to GSAP mixBlendMode + Chrome/Edge = v.low framerate on all animation

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

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

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!).

 

 

  • 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.
×
×
  • Create New...