I presume this is related to how we do the text scaling, or more likely how we choose to optimize painting while animating, and then never clean up the result afterwards.

I'm not seeing any change when enabling/disabling font smoothing in DevTools.

Further insight anyone?

Able to repro without animations.
https://jsfiddle.net/8951da1k/1/

I can confirm i am also getting the same problem. It seems to be specific to OSX running on a retina (2x) screen, this is my criteria:

-webkit-font-smoothing: antialiased;
transition: transform;

Then applying a transform e.g:

transform: translateY(100px);

I think that the will-change property is causing the paragraph to be drawn at scale 1 then transformed to scale 0.8, whereas the 2D scaled 0.8 paragraph is having the test size scaled then painted at that size. The will-change is telling the browser that the transform will be animated, so we render it once at scale 1 ready to transform to any size.

The interaction between the anti-aliasing and the scaling changes the text appearance. In both cases it is anti-aliased.

This is intended behavior and should be WontFix. Assigning to chrishtr@ for confirmation.

I dont really understand, why is 'scale' affecting it if i am just using
translateY?

tom.brickman@, we need your reproduction case if the will-change and scale is not involved.

I really can't believe that the intended behavior is that two blocks of text of the same font size, font weight and color look different. Bug or not, this is new in 54, and differs from safari and Firefox on OSX.

Im wondering if mine is the same bug as mine is specific to retina/2x screens. I will post my reproduction case in a new issue i guess.

I have also only tested on a retina display

I was able to test the linked jsfiddle on a non-retina mac running chrome 53. I was not able to reproduce the issue. I then updated chrome on that mac to 54, and was able to reproduce.

Deleted: osx-chrome-53-non-retina.png 45.3 KB

	osx-chrome-53-non-retina.png 45.3 KB View Download

Deleted: osx-chrome-54-non-retina.png 79.2 KB

	osx-chrome-54-non-retina.png 79.2 KB View Download

That makes sense then. Yes i think this is only a bug on retina displays, we have several non retina Macs with the same version of chrome which have absolutely no problems. We have a few retina devices and they all have the same issue.

Here is my test case:

Chrome 53.0.2785.143 (64 bit)
Mac OS X 10.11.5
RETINA/2X SCREEN

have tested this issue:
Safari: OK 9.1.1 (11601.6.17)

Steps to reproduce:
- Go to https://jsfiddle.net/DG55/5wdtfw1j/1/
- Compare left and right text

You can also replicate by using the following settings:

-webkit-font-smoothing: antialiased;
transition: transform;

Then use the transform property e.g.
transform: translateY(200px)

You can then force the text rendering to update correctly by changing a property on the element, such as unselecting and reselecting 'font-smoothing' or even just changing the width/position as it seems to properly 'repaint'.

Deleted: Screen Shot 2016-11-01 at 19.50.30.png 191 KB

	Screen Shot 2016-11-01 at 19.50.30.png 191 KB View Download

Here is another test case which does not involve scale or the will-change property: https://jsfiddle.net/5q9uktqo/

At my screen, the text appears thick/bold during the animation. After the animation is complete the text looks normal, since there is no longer a will-change property keeping it from being repainted.

Yes that is happening for me too. I didnt realise that your test case was to do with this 'will change' thing, i have never used that.

I was actually doing this in a different way, with a simple 'transition' property and then adding a class. In my case, even without the will change, it always shows the incorrect rendering.

See here:

https://jsfiddle.net/DG55/7ks3Lhb1/

Chrome Canary on my Retina display looks to me like the non-animating case through the animation, on both the examples in comments 14 and 15. Devtools Rendering tab repaint visualization confirms that we composite and do not repaint the text while animating, so one would expect it to maybe look different as it is composited at various animation offsets.

In all cases the text quality recovers when the animation completes and matches, pixel for pixel, the non-animated content. That is, unless you use will-change, which tells the browser that you expect to animate it again, so we do not repaint because as the developer you are implying that's a waste of resources. See https://developers.google.com/web/updates/2016/09/re-rastering-composite

Regarding comment #9; While the text is defined the same, the context in which it is rendered is different. In one case we know that the content is fixed and it's worth making it look good as this is the dominant form of content intended for users to read. Animated text has a different set of requirements. It should be smoothly animating, and overall quality is less important because it is unlikely the author intends the text to be read while animating, at least at a font-size where some blurring makes a readability difference.

The will-change property is explicitly telling the browser that animation is imminent and we should treat it like it's already animating, so as to avoid performance glitches when animation begins. If that's not the developer's intention, then they should not use the will-change property. (Or they might use the will-change property to prevent a blur-to-sharp transition at the end of the animation).

There's probably some way you can prevent Chrome from compositing the animation, but I can't think of it right now.

Linux screenshot of the original reported fiddle.

Deleted: Screenshot from 2016-11-01 17:05:28.png 48.0 KB

	Screenshot from 2016-11-01 17:05:28.png 48.0 KB View Download

I see your point about different contexts, but I still don't see why that necessarily means that it has to be rendered visually different. Font rendering during animations has always worked flawlessly and smoothly in chrome up until 54 on all devices that I've tested.

From an aesthetic point of view this bold text is a problem. And even if will-change or 3D-transforms are not used, the highly visible repaint at the end of the transition is not any better. You might argue that aesthetics don't matter, but myself and I'm sure many others rely on being able to deliver high quality products to our customers.

Re #18, using "will-change: contents" will prevent the animation from being composited, e.g., see https://jsfiddle.net/5q9uktqo/1/

I can see some darker-ness during animation on 54.0.2840.71 / Mac / non-retina with
the example in comment 15. Adding will-change: transform to it has no effect.

On Retina screens, I can see no problems at all for any of the examples so far.

On Linux I see something similar to that reported in comment 19, but it does not look
like anything significant.

Mac OSX 10.11.6
Chrome Version 54.0.2840.87 (64-bit)

I think I am seeing a very similar problem to this reported issue without the css animation.

On napster.com, I have a Napster logo that is inserted on the page as a font.

See the screenshots below for the 4 cases, and focus on the Napster logo in the top right corner.

Comparison 1
1. Mac Display Retina - showing the logo at 162px.
2. Mac Display Retina - showing the logo at 163px.

Comparison 2
3. Macbook Pro Retina - showing the logo at 270px.
4. Mac Display Retina - showing the logo at 270px.

In Comparison 1, just by increasing the font size by 1px, the logo looks blurry and fatter.

In Comparison 2, when you are on Mac Display Retina instead of Macbook Pro Retina, you can see that the logo looks blurry and fatter.

The problem doesn't happen with other browsers. Check on Safari, FF and Brave.

tagwords: font, font-size, icon, glyph

Deleted: mac-display-retina - 162px.png 516 KB

	mac-display-retina - 162px.png 516 KB View Download

Deleted: mac-display-retina - 163px.png 516 KB

	mac-display-retina - 163px.png 516 KB View Download

Deleted: macbook-pro-retina - font-size-270px.png 1.5 MB

	macbook-pro-retina - font-size-270px.png 1.5 MB View Download

Deleted: mac-display-retina - font-size-270px.png 519 KB

	mac-display-retina - font-size-270px.png 519 KB View Download

Seeing this issue on a non-retina mac. New in Chrome 54.

After css transform transition, typographic elements in transitioned elements loose their original antialiasing and become much stronger/jagged.

Compare the headings of the 2nd and 3rd elements in the attached screenshots, before and after transition (1st element is not transitioned).

As another person commented, manipulating any CSS property of the element in the inspector, kicks rendering back to its original state.

Deleted: before.png 117 KB

	before.png 117 KB View Download

Deleted: after.png 117 KB

	after.png 117 KB View Download

Still would like a bisect on this one.

Re comment 24: please provide a test page we can examine.

Able to reproduce the issue on MacBook Pro (Retina) using latest canary #56.0.2913.3 but unable to reproduce the same on chrome reported version #54.0.2840.71 and latest stable #54.0.2840.87 by following the steps as per comment #0.

Also unable to reproduce the issue on Ubuntu 14.04 and Windows-10.

Bisect Information:
=====================
Good build: 56.0.2901.0   Revision Range(427541)
Bad Build : 56.0.2902.0	  Revision Range(427892)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/290242e6b8ad0dceb420758f86dc0c96febcaae1..57d1a4fe85b070baff03ce36f156ee99a71b0cc1

From the above change log could not able to find the suspect.

chrishtr@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

I'm finding this problem a bit baffling and cannot reliably replicate it. I have tested between about 5 different Macs, all using the same version of Chrome on the same version of OSX. 

The problem happens consistently on TWO of the retina macs and I cannot shift the problem, I have a third retina mac where the issue does not happen at all, and two non-retina macs which also do not show the issue.

In fact, two of these machines are actually brand new and have both been cloned from the same OSX disk, so they are identical in terms of hardware. The only difference i can perceive is that they have a different graphics card, so perhaps it only applies to certain graphics drivers??

macbook pro 15 inch retina = YES
imac 21 inch retina = YES
imac 27 inch retina = NO
imac 21 inch non retina = NO
imac 21 inch non retina = NO

As per comment #27, please find the following test page:

https://jsfiddle.net/z4x5c13p/

Attached screen shots of the jsfiddle show the issue, which I have been able to replicate on the following devices, all running chrome 54:
macbook pro 13" retina
macbook pro 13" retina with external non retina monitor
imac 27" non-retina

Deleted: before.png 12.8 KB

	before.png 12.8 KB View Download

Deleted: after.png 14.1 KB

	after.png 14.1 KB View Download

The only change that seems potentially relevant in the changelog from comment #28 is the Skia roll, maybe the change there related to distance fields, but that was a reversion change, which makes me doubt it.

Regarding different Mac's behaving differently. Some bugs only reproduce when the Scrollbar behavior System Preferences are in one or the other states. If you're seeing inexplicable behavior, try verifying those settings.

Testing team: on what example page did you reproduce to end up with the bisect
in comment 28?

Got the bisect range by following the steps as per comment #0 and used the URL: https://jsfiddle.net/8951da1k/ to test this issue.

Please let us know if any more info is required from our side.

Thanks...!!

> Please let us know if any more info is required from our side.

chrishtr, what are next steps here?

I still can't reproduce this issue. Testing team, could you please record a video
of what you are seeing?

Tested in chrome canary #57.0.2955.0 on Mac 10.12.2 and able to reproduce the issue as per comment #0.Please find the screen cast for your reference.

Thank you!

Deleted: 660339.mp4 543 KB

	660339.mp4 543 KB View Download

Also able to reproduce https://jsfiddle.net/8951da1k/ on a 21 inch non-retina 2012 iMac (NVIDIA graphics). On a 21 inch non-retina 2010 iMac (ATI graphics), there's no issue. Both on Chrome 55.

Deleted: 2010.png 11.4 KB

	2010.png 11.4 KB View Download

Deleted: 2012.png 12.3 KB

	2012.png 12.3 KB View Download

Re #38, thanks for testing! I'm guessing that the difference between the two machines is that we're using GPU raster on the newer one and software raster on the older one. Just to confirm, could you go to chrome://gpu on the two machines and look at the "Rasterization" line? If this really is caused by GPU raster, it seems like a duplicate of  issue 668723  (where the problem is that with GPU raster, we're using distance field text on animated layers).

#39: Yes - this actually seems to tie in with the two machines i am testing on at the moment.

Using that link:

1. Rasterization: Hardware = buggy (AMD Radeon R9 M370X)
2. Rasterization: Software = no issues (AMD Radeon R9 M395)

However, what I don't understand is that the graphics cards are both very similar, and the explanation for hardware acceleration being turned off doesn't actually tie in with my graphics card model. 

The error says:

"Some GPUs on Mac can perform poorly with GPU rasterization. Disable all known AMD GPUs other than the R200, R300, and D series, which have been tested.: 613272, 614468
Disabled Features: gpu_rasterization"

That seems to suggest that hardware acceleration should be disabled on both of these machines?? Neither of them are R200 R300 or D series.

+ericrk, see #40, is the Radeon R9 M370X meant to be blacklisted or is the blacklisting error message just stale?

I can't reproduce on my macbook retina by forcing GPU raster on and off. It
seems it might be a GPU hardware-specific problem. Sending to you Eric.

Sounds like we should relax the blacklist to not exclude the M370X - this may have been an error on my part when constructing the blacklist. "R300/R200" was a bit of a typo, should read "Rx 300 / Rx 200", M shouldn't matter, so both these cards should be whitelisted.

We landed a fix for  crbug.com/668723 , so I assume this issue will be fixed as well. Will confirm now.

Fix confirmed in 57.0.2971.0 - duping to  issue 668723 . Merging fix to M56.