Jump to content
GreenSock

joe_midi

Chrome 49 - Janky GSAP

By joe_midi, in GSAP. Views: 13,394

Recommended Posts

Posted

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
  • Replies 80
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Carl
Carl

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

Jonathan
Jonathan

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.  

Jonathan
Jonathan

Thanks for reporting this Technics1210,   That would make sense since Google Chrome will break something, then you will have to do a fix with adding perspective. Then they will fix that previous thi

Posted

Thanks for the additional info NDF :)

Link to comment
Share on other sites
Posted

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
Posted

What about IE and Edge? They have the same problem.

 

EDIT: And I see you posted about that somewhere else. There's too many of these topics open right now. Can we lock the other ones down? I'll let you decide  ;-)

  • Like 2
Link to comment
Share on other sites
Posted

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
Posted

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

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
Posted

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
Posted

Appreciate the hounding. I think the key was to mention how well Safari and Firefox perform in comparison, so thanks Carl!

 

DB

Link to comment
Share on other sites
Posted

Appreciate the hounding. I think the key was to mention how well Safari and Firefox perform in comparison, so thanks Carl!

 

DB

 

Haha! Even better, tell them IE 8 next time.

  • Like 2
Link to comment
Share on other sites
Posted

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
Posted

i just checked my demos in 50 and they look great. YES!

Link to comment
Share on other sites
  • 4 months later...
Posted

The Janky zoom is back!!!

 

Chrome 53.0.2785.116 Win7

 

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

 

I DON'T BELEIVE THIS! Frustrating. I have a few running campaigns with zooms in them.

  • Like 1
Link to comment
Share on other sites
Posted

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
Posted

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
Posted

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
Posted

You are right Jonathan. I see now this is not the solution. I give up and will bring this issue to my client's attention. :(

Link to comment
Share on other sites
Posted

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
Posted

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
Posted

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
Posted

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
Posted

Now I'm seeing the jitter on scaling - can we do what we did last time and inform them that the competition seems to have a better handle on things? That seemed to light the right fire....

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
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
Login Create Account