Jump to content
Search Community

Split text shaking during animation

jstafford 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

That's a Chrome rendering bug and it's super annoying, I know. Chrome has been tweaking the way they handle rendering transforms for a while, and it has largely been very, very bad. See http://greensock.com/will-change/.

 

I just tweaked that codepen to improve it by:

  • Setting will-change:transform in the CSS. 
  • delaying the animations so that they start about 1 tick after the initial render. Silly, I know - this should not be necessary. But watch what happens when you remove the delay (shift the code from inside the delayedCall() to outside of it). Anything that starts with a small scale will look HORRIBLE when scaled up, like a blurry mess. Thanks Chrome! They decided to capture the raster version of the element(s) at whatever size they're initially at, and then never re-sample, so it's taking a super tiny image and stretching/scaling it up. Yuck. I made a bunch of suggestions to the Chrome team for handling this better, but they opted not to listen. 

We reported the bug to Chrome a long time ago. https://bugs.chromium.org/p/chromium/issues/detail?id=596382. They claim to have resolved things, but clearly they haven't.

 

One other thing you can do that makes it look better is to set force3D:false and add a slight rotation, like even 1 degree. The down side to force3D:false is that Chrome decided to make that re-sample the image on every tick (at least that's my understanding), so it's more CPU-intensive. 

 

Again, these are all problems with Chrome and the way it decided to "improve" rendering (obviously I think it's a huge step backwards). I'd encourage you to let them know what you think. The more they hear from the community, the more likely they'll fix things (for real). ;)

  • Like 3
Link to comment
Share on other sites

@GreenSock @Carl

 

Are you serious!!! 

 

I just checked, and it seems v59 does not change how scaling text works. The issue I saw with the update causing blurry text in my scroll header demo isn't related to scaling...

It's caused by autoAlpha.  I guess changing the visibility causes it reraster.

 

With autoAlpha...

 

Without autoAlpha...

See the Pen ?editors=0010 by osublake (@osublake) on CodePen

 

5 hours ago, GreenSock said:
  • delaying the animations so that they start about 1 tick after the initial render. Silly, I know - this should not be necessary. But watch what happens when you remove the delay (shift the code from inside the delayedCall() to outside of it). Anything that starts with a small scale will look HORRIBLE when scaled up, like a blurry mess. Thanks Chrome! They decided to capture the raster version of the element(s) at whatever size they're initially at, and then never re-sample, so it's taking a super tiny image and stretching/scaling it up. Yuck. I made a bunch of suggestions to the Chrome team for handling this better, but they opted not to listen. 

 

You need to be careful here. I have not been able to figure out how much time must pass before the element gets rasterized. From what I can tell, it takes at least 2 animation frames. Sometimes more. I think running that demo inside CodePen might be messing with the timing. On a fresh page load, it should look like this.

 

LyYgQU2.jpg

 

  • Like 1
Link to comment
Share on other sites

Nuts its is Good Sirs..

 

I'm curious if internally to test, if you had GSAP set the visibility property be set to "visible" instead of "inherit" while interpolating autoAlpha.. what type of behavior Chrome would do? Since inherit is more of a global CSS visibility value instead of an actual value  which is either "visible",  "hidden", or "collapse". It looks the spec shows the interpolation of visible as a discrete step whereas inherit is not mentioned in the Animation of interpolated Property Types spec. Maybe Chrome is misinterpreting "inherit" in this case since it has been real sloppy lately.

Link to comment
Share on other sites

@OSUblake@GreenSock, and @Carl

 

To get rid of that blurry text not related to scaling in Chrome you need to add both perspective and transform-style to the parent (.header-content) of the .small-title and .large-title the blurriness goes away. Chrome needs those properties to apply the snapshot correctly since CSS will-change triggers new layer context. CSS will-change replaced the transform: -webkit-translateZ(0) hack.

 

And those missing CSS properties let the browser know its hardware accelerated since  perspective and transform-style tell browser its a 3d context. I also tested with transformPerspective and that also works on the element itself. Which is the same anti-aliasing webkit bug from Chrome 19. So basically the same Chrome bugs are still infesting our animations. Tested in latest Chrome and i saw no blurry rasterized text. ;)

 

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

 

.header-content {
  position: relative;
  height: 100%;
  width: 100%;

  -webkit-perspective:1000px; /* needed to prevent bluriness in chrome with will change */
  -webkit-transform-style:preserve-3d; /* optional but best to include to prevent bluriness in chrome with will change */
}

 

:)

  • Like 2
Link to comment
Share on other sites

4 hours ago, Jonathan said:

Nuts its is Good Sirs..

 

I'm curious if internally to test, if you had GSAP set the visibility property be set to "visible" instead of "inherit" while interpolating autoAlpha.. what type of behavior Chrome would do? Since inherit is more of a global CSS visibility value instead of an actual value  which is either "visible",  "hidden", or "collapse". It looks the spec shows the interpolation of visible as a discrete step whereas inherit is not mentioned in the Animation of interpolated Property Types spec. Maybe Chrome is misinterpreting "inherit" in this case since it has been real sloppy lately.

 

Unfortunately we really need to use visibility:inherit instead of visibility:visible because otherwise it breaks inheritance and can get weird. Imagine if you've got something nested inside a container - if you set visibility:hidden on the container, you'd expect it to hide children of that container...but if any of them have visibility:visible, it forces it to be visible. So you could have a visible child in a hidden parent. See what I mean? 

Link to comment
Share on other sites

Thanks jack,

 

I understand you need to keep it as visibility inherit. ;)  I was just talking about doing a temp change in your local CSSPlugin file to see if visibility inherit was causing an issue in Chrome for what Blake posted about autoAlpha. To see if Chrome introduced a new render bug with CSS visibility. 

 

But based on my second post it looks like its more of an issue with Chrome changing again how stuff renders, as usual. It looks like will-change needs other CSS properties like perspective to fix the blurry snapshot like it used to in Chrome 19 and Chrome 29. When they fixed it so you didnt need other CSS properties to fix their blurry or jitter bugs..  but then they fixed it .. and then broke it.. and then fixed it again..  to yet again break it again. :)

Link to comment
Share on other sites

Yeah serious.. ive been following that.

 

I see the same type of constant changing things in their UI/UX for their apps. I dont think they even follow their own Material Design guidelines, because the past 5 years their UI and UX have been really anything but usable with constant changes of features and layout. Not to mention that stupid AMP (accelerated mobile pages) stuff that now they give SEO ranking preference too and force AMP search results.

 

Some of there responses in that thread  especially their solution is really weird like in comment #122. Asking you to paste a CSS animation rule in your codepen. Not even sure why they thought that would solve an issue creating needless CSS animation rules and @keyframes. Its weird how they say its hard to implement JS driven animation when in previous versions of Chrome, like 8-9 versions ago they had it working and then broke it again.. like twice.

 

Here is a codepen with there proposed solution (forked from your codepen with their keyframes animation).. very weird behavior (view in Chrome):  .. its like we are trading full blown blurry jitter for a semi-blur mumbo jumbo.

 

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

 

Lets see what they say to your last response. Pretty weird to drive the JS animation on the creation of some fake CSS animation that wont even run. I found that very odd when i first read his response, and that their solution will get very hairy, very quickly. :(

  • Like 2
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...