Jump to content
GreenSock

G. Scott

Scale + Chrome

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

I'm wondering if there is any solution to the jerky performance in Chrome when using scale. Getting stuck between a rock and a hard place here. If I use scale to zoom images in and out (ie if creating a Ken Burns effect), it looks beautiful in every browser except Chrome for some reason. VERY jerky. But if I simply animate width and height, it looks perfect in Chrome, but terrible in Safari.

 

Scale is my first choice because its less code and allows for transformOrigin, etc... super slick! However I have been avoiding it solely because of the way it performs in Chrome. My solution thus far has been to animate the width and height of background images instead... which oddly enough, works smoothly in all browsers. 

 

And THESE are the times I miss Flash... :(

Link to comment
Share on other sites

Yes, Flash certainly had its advantages in some areas.

 

What I have found for scaling text in chrome is that if you give the element a very slight translateZ value the scaling is much smoother.

 

Take a look at this demo:

See the Pen AGzci by GreenSock (@GreenSock) on CodePen

 

 

not jerky at all. This is the secret sauce:

TweenLite.set(element, {autoAlpha:0, scale:0, z:0.01});

Let us know how that works for you.

  • Like 5
Link to comment
Share on other sites

Carl, THANK YOU SO MUCH! Silky smooth now... even more so than when I was animating the bg images. The only problem I had was that the images jumped momentarily over top of another layer (png with transparency). Setting the z to a negative value (z:-0.01) solved that problem.

 

You are the bomb!

 

Guy

Link to comment
Share on other sites

Ah, thanks for the negative z tip. Glad it all worked out.

Link to comment
Share on other sites

Glad you guys figured it out. And just to clarify, I believe the slight z translate works because it forces 3D rendering of that element in the browser, which typically also pushes it to the GPU and it has to get antialiased a bit differently than a 2D element. In most scenarios, this works great, but be aware that the GPU has memory limits and if you have hundreds or thousands of elements all animating in 3D simultaneously, you can run into performance problems that you wouldn't if you kept stuff in 2D. But that's pretty uncommon. Just thought I'd mention it. 

 

One other tip: I've noticed that in Safari (including iOS), if you set the opacity to something other than one (even 0.999), it can help things animate a bit more smoothly under pressure. But in Firefox, that has the opposite effect :(

  • Like 2
Link to comment
Share on other sites

  • 3 months later...

but using 3D rendering would only work when the browser supports WebGL, right? So no fix for IE9?

Link to comment
Share on other sites

Hi and welcome to the forums.

 

Since IE9 can't render any 3D stuff adding the small z tween or force3D:true in the tween vars won't have any effect.

 

What you could do is use modernizr in order to detect IE9 and create an alternative animation script as a fallback. Check this post for more info:

 

http://forums.greensock.com/topic/7256-ie-9-fallback-for-3d-transform/

 

Best,

Rodrigo.

  • Like 2
Link to comment
Share on other sites

Sweet hack Carl!

 

I got around this same chrome bug awhile back by applying the below to the stylesheet on the element i was scaling. Its similar to Carl's hack, but instead it is applied on the target element when the style sheet is loaded:

#targetElement {
     transform: scale(1) rotate(0deg) translate3d(0, 0, 0.1px);
}

by having the translate3d in the transform property, it will trigger hardware acceleration if the browser supports it, when the style sheet is loaded. And the 0.1px in the Z value will offset the element slightly to fix chrome's jerkiness.

Link to comment
Share on other sites

Just for the record, the GSAP "3D stuff" has nothing to do with WebGL - it's just 3D css transforms which are a completely different beast. 

  • Like 1
Link to comment
Share on other sites

Just so i clarify when i was talking about hardware acceleration,  i was referring to how hardware acceleration allows the browser to offload the graphics rendering from the CPU (processor) to the GPU (graphics card).. which like Jack said has nothing to do with WebGL. And please correct me if im wrong Jack, thanks :)

Link to comment
Share on other sites

Exactamundo. Although WebGL does that too. But yeah, we're strictly talking css 3D transforms here.

Link to comment
Share on other sites

  • 2 years later...

Yes, Flash certainly had its advantages in some areas.

 

What I have found for scaling text in chrome is that if you give the element a very slight translateZ value the scaling is much smoother.

 

Take a look at this demo:

See the Pen AGzci by GreenSock (@GreenSock) on CodePen

 

 

not jerky at all. This is the secret sauce:

TweenLite.set(element, {autoAlpha:0, scale:0, z:0.01});

Let us know how that works for you.

 

You save my day brother! It's so smooth now! thanks!

Link to comment
Share on other sites

  • 2 months later...

Hi, 
Same problem here. 
I created a pen to show the issue: 

See the Pen ZppQBk by LorenzoBocchi (@LorenzoBocchi) on CodePen

 

It's completely fine in Firefox and Safari. 

On Chrome is very very slow.

 

I've already tried using smaller images or call the image in the HTML instead of the CSS. Nothing. 

The weird thing is that in my actual build, during the entire animation the rest of the website "freeze".

I'm also using Parallax.js and until the animation is completed the entire experience is not smooth at all. 

Chrome MacOs Sierra Version 53.0.2785.116 (64-bit)

Link to comment
Share on other sites

Hm, it looked super smooth for me in Chrome. It kinda sounds like a Chrome bug that was discussed here: 

http://greensock.com/forums/topic/13875-chrome-49-janky-gsap/

 

It had to do with background-images. Have you tried changing to just using an <img> inside a <div> or something? That might work around Chrome's bug. I'm pretty confident this has nothing to do with GSAP. 

Link to comment
Share on other sites

It looks smooth for me in Chrome as well. It looks like what is happening is that the DOM and window is not fully ready and loaded yet. That is why it stutters at the beginning of page load, but not on subsequent reloads. Since that is  every large image  your loading ;)

 

See the Pen zKKPoj by jonathan (@jonathan) on CodePen


 

// wait until DOM is ready
document.addEventListener("DOMContentLoaded", function(event) {
  
  // wait until all images, links and css are loaded
  window.onload = function(){
      
        TweenMax.to('.intro-background', 13, {
            scale:1, 
            force3D:true
        });
  
  };
  
});

You should always run your code only when the DOM and window is fully loaded and ready. So this way your animation runs when the page is ready to have stuff animated.

 

Hope this helps! :)

  • Like 2
Link to comment
Share on other sites

I Jonathan, 
Thanks for your answer and your Pen. 

Actually, I'm still having the same issue as before, even with your example. 

In my build, I've called the animation after the loader of the DOM too, as you've suggested. 

 

And yes, I've tried both solutions with the image in the CSS or the HTML. Same thing. 
I think this is a browser issue at this point. Especially considering that you can see it properly.

 

I'm on Mac OS Sierra, Chrome 53.0.2785.116 (64-bit)
 

Cheers

Link to comment
Share on other sites

Chrome has definitely botched the way it rasterizes elements with background-image in version 53. We have been going back-and-forth with them here: https://bugs.chromium.org/p/chromium/issues/detail?id=596382

 

I really hope they fix it soon. 

 

In the mean time, I noticed that your example looked **much** better when switched to a regular <img> instead of a <div> with background-image. Chrome uses a different algorithm for rasterization and scaling of <img> elements (weird, I know). 

  • Like 3
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.
×