Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
joe_midi

Chrome 49 - Janky GSAP

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

Share this post


Link to post
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!

 

:)

Share this post


Link to post
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.

 

Adding:

div {
  transition: all 0.1s;
}

and

force3D: true;

Seems to alleviate the issue.

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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?

 

Thanks!

Share this post


Link to post
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

 

http://codepen.io/GreenSock/pen/rexpMG

 

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

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

//good
TweenLite.to(something, 1, {x:100, force3D:true});
  • Like 5

Share this post


Link to post
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!

Share this post


Link to post
Share on other sites

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

CSSPlugin.defaultForce3D = true;

Share this post


Link to post
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. :)

 

Thanks

- P

Share this post


Link to post
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.

https://github.com/DangerPenguin/FireSprite/blob/master/FireSprite.js

Share this post


Link to post
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.

Share this post


Link to post
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.

https://davidwalsh.name/convert-canvas-image

 

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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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:

https://bugs.chromium.org/p/chromium/issues/detail?id=573146&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&start=100

 

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 :)

Share this post


Link to post
Share on other sites

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

:(

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

 

http://codepen.io/GreenSock/pen/rexpMG?editors=1000

 

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

  • Like 1

Share this post


Link to post
Share on other sites

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

 

 

it's better at full size.

  • Like 2

Share this post


Link to post
Share on other sites

Thanks for making this into a YouTube video Carl :)

Share this post


Link to post
Share on other sites

Submitted a bug-report...

  • Like 2

Share this post


Link to post
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 ;)

Share this post


Link to post
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

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. 


  • Recently Browsing   0 members

    No registered users viewing this page.

×