Jump to content


Chrome 49 - Janky GSAP

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

Hey all, 


Anyone notice their animations go a bit screwy in the latest release of Chrome?


For the most part it's anything transform based.

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

Link to comment
Share on other sites

Hello joe_midi, I am not seeing this behavior.


Here is an example of an element rotating with transforms and i am not seeing any jank. Tested on Windows 7 (64-bit) on latest Chrome 49 (Version 49.0.2623.75 m).


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

  • On what OS are you seeing this on? ...  Windows 7, Windows 8.1, Windows 10, or iOS?
  • Do you have a codepen example so we can see what your seeing?


Any additional info will be helpful, thanks!



Link to comment
Share on other sites

Mac OSX 10.11.3 (15D21) - Chrome Version 49.0.2623.75 (64-bit)


Apologies guys, this is a banner post, but I posted it in this forum because I believed it to be a wider issue.


This is the default template bannertime banner:

See the Pen eJMYyg by joemidi (@joemidi) on CodePen


On Chrome 49 isn't as fluid as it used to be.


Safari/Firefox still look fine.

Chrome 48 looks fine.



div {
  transition: all 0.1s;


force3D: true;

Seems to alleviate the issue.

  • Like 1
Link to comment
Share on other sites

Looks like you are mixing GSAP with CSS transitions and CSS animations, which will cause buggy behavior. Both will have a slug-fest for the same elements and elements children.


You really should not be targeting elements or elements that have children that are being animated by CSS transitions and CSS animations, or you will have conflicts like your seeing. This is due to both GSAP and CSS animations/transitions competing to animate the same element or child of an element your animating with GSAP. So there will be conflicts..


So as a rule of thumb either use GSAP to animate your elements, but not both GSAP and CSS transitions and CSS animations. Doing so will cause jank, buggy behavior and unforeseen rendering and or no animation.



  • Like 3
Link to comment
Share on other sites

I don't really think thats the issue, seeing as it's worked fine since we created this template in 2015, its only happened overnight when Chrome 49 was released, we also encountered another issue with backface-visiblity in Chrome 49, which was not correctly painting itself on the screen.


Even if I did comment out the preloader's CSS spin animation, the jank is still quite visible.

.preloader {
  background: #fff;
  height: 100%;
  width: 100%;

  .circle {
    border: $preloader-width solid #ddd;
    border-bottom-color: #333;
    border-radius: 50%;
    height: $preloader-size;
    left: 50%;
    margin-left: -($preloader-size + $preloader-width) / 2;
    margin-top: -($preloader-size + $preloader-width) / 2;
    position: absolute;
    top: 50%;
    // transition: all 0.7s ease-in-out;
    // animation: spin 0.5s linear infinite;
    width: $preloader-size;

// @keyframes spin {
//   from {
//     transform: rotate(0deg);
//   }
//   to {
//     transform: rotate(360deg);
//   }
// }
  • Like 1
Link to comment
Share on other sites

is there any reason why you just dont spin the preloader with GSAP and not CSS animation?


I am not seeing this jank on windows.. Maybe someone on Mac OSX 10.11.3 (15D21) and the latest Chrome Version 49 can see if they see the same thing?


Since even on Windows Chrome i am not seeing any jank.. Windows 7 in latest Firefox has nothing animating, not even an image displaying.


Can you describe the jank your seeing in more detail fro those of use not seeing what your seeing?



Link to comment
Share on other sites

Hi Joe,


Thanks for the report. 


I just updated to Chrome 49 on Mac and I'm seeing what I might refer to as "pixel snapping" at the very end of the elastic ease while scaling.

It appears to be related to the fact that you are scaling a div with a background image.


Here is a reduced demo




note: I know you were just experimenting but you were putting force3D in the timeline constructor improperly. force3D can only be applied to tweens

new TimelineLite({onComplete: loop, force3D: true});

TweenLite.to(something, 1, {x:100, force3D:true});
  • Like 5
Link to comment
Share on other sites

Thanks Carl!


Hmm, perhaps we need to re-think how we use images I guess.


Out of curiosity, how would one force3D globally?


I'll also write a reduced demo for the backface-visibility bug at some point as well.


I hope Chrome 50 comes soon!

Link to comment
Share on other sites

By default CSSPlugin uses force3D set to auto. You can change that globally using

CSSPlugin.defaultForce3D = true;
Link to comment
Share on other sites

Hey Carl, I wanted to comment because switching all images to use the img tag affects my current workflow greatly.


I almost always use sprite sheets.

All of the sprite sheet creation tools I have ever used, use background-image and background-position.

My knee-jerk reaction is "how the heck do I switch to img tags?" ARGH!


It never dawned on me to try img tags with sprite sheets, clip-path maybe?

I only used background-image because thats what TexturePacker uses for CSS.

I'll look to see if it can use the img tag but I don't think so.


Anyways, just chiming in. :)



- P

Link to comment
Share on other sites

You can get the computed style of an element to get the url of the background image. However, it might be easier to just parse the JSON, draw your images on a canvas, and then create img elements from the canvas.


I saw this script on GitHub. It looks kind of old, but you might be able to use some of it as a parser.


Link to comment
Share on other sites

Interesting Blake, but that's for canvas right? This issue is CSS related.

Chrome will be updated, transforming the background image shouldn't be any different from img tags.

Link to comment
Share on other sites

Yes, that script is for canvas. I was suggesting to use canvas to create your HTML images. Using canvas to create images is very easy.



So you can use that script to parse the JSON exported by TexturePacker, and then create images from a canvas. Just as an example, the JSON might look like this...

{"frames": [
      "filename": "some-image.png",
      "frame": {"x":266,"y":398,"w":64,"h":64},
      "rotated": false,
      "trimmed": false,
      "spriteSourceSize": {"x":0,"y":0,"w":64,"h":64},
      "sourceSize": {"w":64,"h":64}

That script should draw the image on a canvas using the frame x, y, width, and height. You can then convert the canvas to the src for an HTML <img/>

  • Like 1
Link to comment
Share on other sites

yeah thats very cool but I'm hoping that since this only seems to be a Chrome OSX only issue that it will be fixed (Chrome or GSAP) without having to do a workaround like that.

Link to comment
Share on other sites

I haven't seen any mention of this being fixed, or what's even causing it. So I just threw that idea out there since you were wondering how to create images from TexturePacker.

  • Like 1
Link to comment
Share on other sites

I think Part of the problem is this bug report for chromium webkit that the Chromium dev team said they won't fix this bug


Blurry text in elements with sub-pixel position and 3D transforms:



If you look at that bug report, they say that they wont fix the blurry text on elements with 3D transforms due to sub-pixel rendering. When i tested on Window 10 Chrome 49 i noticed that i was seeing more blurry text fluctuating during the animation. 


Too bad that blurry text wont be fixed on elements with CSS 3D transforms due to teh sub-pixel rendering, and now this new jitter bug just makes the anti-alias bug more frustrating, thanks webkit :)

Link to comment
Share on other sites

so not only are background-image animations jittery, text elements with a transform will also be blurry.


Link to comment
Share on other sites

Hello retropunk, That CSS 3D transform sub-pixel webkit bug has been around for several years now. It is a basically an anti-alias bug. Mostly it can be resolved by setting force3D:false in GSAP.


A couple of years ago in Chrome you could fix it by adding with transform-style preserve-3d and either perspective or transformPerspective. But now and for the past 2 years that wont work anymore. But just to be clear this only affects any elements that have 3D transforms with sub-pixel rendering, that is why force3D:false on your tweens help squash it.


Before that anti-alias bug triggers when scaling above a scale factor of 1 (100%). But now with this new jitter bug the element becomes blurry even if below a scale factor of 1. So we cant win either way :(


Usually when Firefox or iE11 get that jitter motion, then all you have to do is add a slight rotation: 0.01 and or z:0.01 .. and that fixes the jitter in Firefox and IE11.


But again force3D:false solves this anti-alias webkit bug. But now we have this other jitter bug to add to the madness. Hopefully this new bug is reported and gives the Chrome Dev Team some motivation to fix both bugs, since Chrome is making it very difficult to do 3D transforms that are not blurry. Chrome could learn a thing or two from Firefox in how it renders 3D transforms with sub-pixel rendering without the blurry astigmatism. :)

  • Like 4
Link to comment
Share on other sites

Hi everyone,


I can confirm that Chrome 49 on both Windows and OS X seems to have altered the way elements with background images perform when animated. I’ve been working on our studio portfolio these past few weeks and Chrome 49 has rendered a pretty heavy animation that was jank-free before completely egregious.

Switching background images to manually-positioned <img> tags helped me get back to 60fps glory.


That being said and even though this isn’t such an issue in our particular case, I can’t help but think this would be a complete nightmare semantics-wise if Google doesn’t fix it.

  • Like 2
Link to comment
Share on other sites

This issue still persists after upgrading to Version 49.0.2623.87 (64-bit) Mac.


I have updated my demo to make it more clear what is happening.




If anyone wants to use it in a bug report or send to Chrome team, feel free.

  • Like 1
Link to comment
Share on other sites

here is a video for those who do not have Chrome 49



it's better at full size.

  • Like 2
Link to comment
Share on other sites

Thanks for making this into a YouTube video Carl :)

Link to comment
Share on other sites

Submitted a bug-report...

  • Like 2
Link to comment
Share on other sites

Thanks NDF .. do you have a link to that Chrome bug report you submitted?


Just making sure that it shows that this flicker and pixel-snapping bug is only seen on Chrome 49 affecting:

  • Nvidia dedicated graphics cards
  • and some Intel integrated graphics cards

So this way they are made aware of others who narrowed down what computers are affected with the above graphics cards ;)

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.