Jump to content
Search Community

Chrome 49 - Janky GSAP

joe_midi test
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

Hi,

I've no link to the Chrome Bug Report yet - I used the above as an example - so I can only assume it's not been responded to yet.

Try this >> http://dev.andyfoulds.co.uk/asdasd , rollover the buttons at the bottom.

It was silky smooth in Chrome 48. 

 

I have a Win7 PC with an NVidia graphics card but I've also seen this on my Mac at the studio, even got to see it before-and-after as Chrome updated itself!

 

Andy___F

Link to comment
Share on other sites

OK Fellow GreenSockers,

 

Here is the Chrome bug report for this new Chrome 49 flicker pixel-snapping:

 

https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

 

The more people comment on this behavior in that bug report. The faster the Chrome Dev Team can fix this.

 

I just left my comment in detail describing the behavior. But they didn't know that it is being caused by Nvidia and Intel graphics cards.

 

When leaving your comment make sure you leave the following and any other additional examples if you have them.

 

You need to have a Google account to sign in and leave a comment on this Chrome bug issue tracker:

 

https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

  1. OS
  2. OS Version
  3. What graphics card (Nvidia or Intel)  you tested in Chrome 49. (make sure they know this)
  4. Any additional examples showing this behavior.

Carl's code example is being used to describe this behavior. AMD Radeon graphics cards seems to be working fine.

 

Hopefully the more info they have regarding this flicker bug, the faster they can fix it.

 

:)

  • Like 2
Link to comment
Share on other sites

Ok i just locked this other topic and pointed others to this topic, since it has Carl's codepen example and YouTube video showing this behavior.

 

I forgot to include MS Edge, and they don't have an edit comment feature on that bug report tracker. :(

 

On a side note regarding MS Edge. The bad thing about MS Edge is that it allows webkit prefixes and renders like webkit. I have a feeling that the issue in MS Edge and IE can be fixed with a slight rotation:0.01 .. i tried this on a computer with Nvidia graphics card in MS Edge using

See the Pen rexpMG?editors=1000 by GreenSock (@GreenSock) on CodePen

, and i no longer saw the pixel-snapping flicker with a slight rotation.

 

Thanks Blake!

  • Like 2
Link to comment
Share on other sites

Great work, Jonathan.

I just posted on the bug report with a new demo that does NOT use GSAP (just RAF)

http://codepen.io/anon/pen/LNyYrX

 

and a video (watch at full size)

 

anyone else, please "star" this issue that Jonathan created: https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Thanks to everybody who put these janky demos together and explained the issues that this bug is causing to the Chrome team. 

 

I build sites (like this one) with ScrollMagic + GSAP scale tweens, both of which make me look like a champion to my non-techy clients. Smooth scaling is muy importante to me, both in the background (Ken Burns FX, etc) and the foreground (clients want pop; scale pops). This bug came around and screwed that allll up.

 

I've starred the issue and I hope that my clients are using other browsers (or have good graphics cards) until a fix comes though.

 

Blagh, 

 

Dave Bloom 

Link to comment
Share on other sites

Hello Oliver15Years if you follow that Chrome bug report for this issue. The Chrone Dev Team is still working on the issue, since it is intwined with previous scale bug reports.

https://bugs.chromium.org/p/chromium/issues/detail?id=596382

So we just have to be patient, normally this bug would be a Won't Fix, but since we hounded the Chrome Dev Team to death regarding this issue, we got their feet moving ;)

  • Like 1
Link to comment
Share on other sites

This Chrome 49 Jank Bug is now achieved FIXED status:

 

https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

 

If everyone can try out the previous examples and it should behave without jank, jitter or pixel-snapping!

 

Thanks to all that voted up this Chrome bug ticket :)

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

Thanks for reporting this Oliver15Years

 

It looks like this is related to this on going webkit chrome bug found here:

 

https://bugs.chromium.org/p/chromium/issues/detail?id=521364

 

But I'm under the impression that that this bug is back being triggered by something else that they added in Chrome 53, since the above is for text and not background-image. even though this bug can affect both text and background images.

 

https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

 

:(

  • Like 1
Link to comment
Share on other sites

They give this solution:

https://docs.google.com/document/d/1f8WS99F9GORWP_m74l_JfsTHgCrHkbEorHYu72D4Xag/edit

 

Put 

will-change: transform;

in the CSS, but is is making the entire image low rez.

 

Update:
My friend tried everything with everything. This is working:
 

  -webkit-transform: translateZ(0);
  will-change: transform;
 
Update:

This will cause megablurriness on elements whose are zoomed from smaller to bigger scale. :(
  • Like 1
Link to comment
Share on other sites

Be careful with will-change CSS property it should only be used as a last resort. And last time i checked last week, will-change was causing other weird behavior causing massive blurry pixelation on elements. Kind of like a offset Gaussian blur in Chrome.. having the opposite effect.

 

This looks like it works, but it can add other performance and blurriness, so use it at your own risk :)

 

This bug still needs Chromes attention since will-change is a last resort but good find!

  • Like 1
Link to comment
Share on other sites

Any idea why will-change is to be used so sparingly? They used to say that about fats on the food pyramid, but I tried eating 6 baguettes a day and didn't lose my love handles. 

 

Is it bad for a single instance of animation performance, does it affect load times, or repaints..?

 

DB

Link to comment
Share on other sites

Looks like Google Devs replied and suggested will-change.. which is weird their solution is to use a last resort css property to fix a chrome bug. very weird :(

So now you have to create a rendering layer with will-change for any scaled text or images. So not even doing a 2D transform scale and you have to deal with this chrome bug. What happens if your scaling multiple elements.. all elements will need will-change and cause some blur on elements that don't need will change. The best way is to apply will-change is with JS so its not used on the element at all times. But this looks like it needs to be on or set before page load to work properly. Some of the Chrome Devs don't even consider a bug yet other browsers like Firefox IE, Edge, and Safari don't have this buggy jitter or blur. But looks like they consider it normal behavior based on the latest replies to that bug report. How is this not a bug? :(

There might be hope that this will be fixed after further discussion

https://bugs.chromium.org/p/chromium/issues/detail?id=596382&can=2&start=0&num=100&q=chrome%2049&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

Link to comment
Share on other sites

Really shameful that we have to look for a workaround from time to time, when they are coming out with a new version, mess up things that's usually working. :)

We've tried out a few things with and he was right, using "will-change" will pre-cache the pixel asset. So scaling an asset from  <1 to 1 will make it pixelated.

 

Setting this to the asset container seems to fix the problem.

TweenLite.set ( [container] , {webkitPerspective: 1000});

 

 

 

 

  • Like 1
Link to comment
Share on other sites

transform: perspective() CSS function or perspective property used to fix this bug around Chrome version 20, but that has been on and off working to fix it. Then it started with elements scaled above a scale factor of 1 would be blurry. In every Chrome version the previous fix stops working. Just like we are seeing with this old new WebKit blur jitter bug. Fun stuff

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