New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 668723 link

Starred by 16 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Fonts rendered too thin during transform CSS animation

Reported by paul.ne...@gmail.com, Nov 25 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36

Example URL:
https://neave.com/temp/font-issue.html

Steps to reproduce the problem:
Go to https://neave.com/temp/font-issue.html

Observe the animating text. The first line of text at 17px font size animates correctly, using grayscale antialiased fonts during the animation that are the correct font width. This seems to apply for all font sizes <= 17px.

What is the expected behavior?
Both lines of text should appear to have the same font thickness during a CSS transform animation.

What went wrong?
The second line of text at 18px renders too thin during the animation, creating a visible stutter/adjustment as the font switches from subpixel-antialised to grayscale and back again. This seems to apply for all font sizes >= 18px.

The effect is more pronounced with white text on a black background. I have not tested this on Windows, only on Mac.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Approx M52

Does this work in other browsers? Yes

Chrome version: 54.0.2840.98  Channel: stable
OS Version: OS X 10.12.1
Flash Version: 

Here is the example code:

<!DOCTYPE html>
<html>
	<head>
		<style>

body {
	background: #000;
	color: #fff;
	font-family: sans-serif;
	margin: 50px;
}

.p1, .p2 {
	transition: transform 1s linear;
}

.p1 {
	font-size: 17px;
}

.p2 {
	font-size: 18px;
}

.anim {
	transform: translateX(50px);
}

		</style>
	</head>
	<body>
		<p class="p1">17px font rendered correctly during animation</p>
		<p class="p2">18px font rendered too thin during animation</p>
		<script>

function addAnim() {
	document.querySelector('.p1').classList.add('anim');
	document.querySelector('.p2').classList.add('anim');
	setTimeout(removeAnim, 1500);
}

function removeAnim() {
	document.querySelector('.p1').classList.remove('anim');
	document.querySelector('.p2').classList.remove('anim');
	setTimeout(addAnim, 1500);
};

addAnim();

		</script>
	</body>
</html>
 
Components: -Blink Blink>Fonts
Labels: M-54 Needs-Triage-M54
Labels: -Type-Bug -Pri-2 -M-54 hasbisect-per-revision M-56 OS-Linux Pri-1 Type-Bug-Regression
Owner: jaydasika@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12 and Ubuntu 14.04 using latest canary #57.0.2936.0 and latest stable of linux #54.0.2840.100. Unable to reproduce in the chrome reported version #54.0.2840.98. Unable to reproduce this issue in Windows-10.

Bisect Information:
=====================
Good build: 56.0.2907.0	 Revision(429169)
Bad Build : 56.0.2908.0	 Revision(429486)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/f902f2c3194edaffd899ca7a5a9689d2b71568da..b874eddcc31db95ab073c278a880cab0d59e655c

From the above change log suspecting below change

Review url: https://codereview.chromium.org/2473453002

jaydasika@ - 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...!!
Cc: ajuma@chromium.org weiliangc@chromium.org
Components: Internals>Compositing
Couldn't repro on M54 on both Linux and Mac.
Couldn't repro on Linux but able to repro on Mac on canary #57.0.2937.0. 
I see the adjustment of width on Mac Retina at the end of the animation for both 17px and 18px.
The suspect CL got merged into M55, so this should repro there too. I will investigate this further
ajuma@: Do you know if anything could have happened on CSS animation could that could be related to this?

Comment 6 by ajuma@chromium.org, Dec 14 2016

I'm not seeing a difference in the way the animation is rendered in 56.0.2907.0 vs 56.0.2908.0. Also, given that the original report is in 54, I'm not sure if we're all seeing the same thing.

krajshree@, could you upload a screencast of the good/bad behavior you're seeing?
Cc: krajshree@chromium.org
Here's a GIF of the issue - affects current Release & Canary builds, Mac, non-Retina display.
Kapture 2016-12-15 at 21.26.13.gif
534 KB View Download

Comment 9 by ajuma@chromium.org, Dec 16 2016

Cc: vmp...@chromium.org ericrk@chromium.org
Thanks! I bisected this on low-DPI Mac to https://codereview.chromium.org/1992603002 which enables GPU raster on Mac (that was in M53). Also verified that this stops reproducing if I disable GPU raster.

This is happening because PictureLayerImpl::UpdateTiles enables distance field text when the layer's transform is animating. When the animation finishes the layer is destroyed, and the text is now in a layer that doesn't have distance field text enabled, so the text looks different.

The point of using distance field text for transform animations was to improve the appearance of scale animations back when GPU rasterization would re-raster every frame during such animations. Since we're not re-rastering every frame during animations anymore, I think we should stop rastering text differently for animated layers.

Comment 10 by ajuma@chromium.org, Dec 16 2016

Components: -Internals>Compositing Internals>Compositing>Rasterization
Cc: tkonch...@chromium.org
Just to update:

Still able to reproduce the issue on Linux chrome version 57.0.2952.0

Comment 12 by ajuma@chromium.org, Dec 16 2016

tkonchada@: Is what you're seeing on Linux exactly like the GIF posted in comment 8 (where only the second line changes significantly), or is it that both lines look thinner during the animation? I think the latter is a different bug.
Able to reproduce the issue on Mac 10.12.2 using chrome version 57.0.2956.0.Observed only the second line of text rendered as thin during the animation.

Thanks,
Cc: jaydasika@chromium.org
Owner: ericrk@chromium.org
Re-assigning based on comment 9
Per comment #9, going to put together a patch to disable distance-field text during animations, which should address the issue.

bsalomon@ - out of curiosity, is this level of difference between DF / non-DF text expected?
Project Member

Comment 16 by bugdroid1@chromium.org, Jan 3 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b04a4a62bc244a238e63c6862be0ed6dfe84a837

commit b04a4a62bc244a238e63c6862be0ed6dfe84a837
Author: ericrk <ericrk@chromium.org>
Date: Tue Jan 03 20:48:08 2017

Don't use DF text during animations

Previously, we enabled distance-field text during animations in
order to improve GPU raster performance. Now that GPU raster
handles animations the same way as SW - only rastering at specific
scales and interpolating, this optimization isn't necessary.

In certain cases, the optimization causes visual differences
between non-animating and animating content, so removing this
improves our correctness as well.

R=ajuma@chromium.org
BUG= 668723 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2605273003
Cr-Commit-Position: refs/heads/master@{#441204}

[modify] https://crrev.com/b04a4a62bc244a238e63c6862be0ed6dfe84a837/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/b04a4a62bc244a238e63c6862be0ed6dfe84a837/cc/layers/picture_layer_impl_unittest.cc
[modify] https://crrev.com/b04a4a62bc244a238e63c6862be0ed6dfe84a837/cc/playback/raster_source.cc
[modify] https://crrev.com/b04a4a62bc244a238e63c6862be0ed6dfe84a837/cc/playback/raster_source.h
[modify] https://crrev.com/b04a4a62bc244a238e63c6862be0ed6dfe84a837/cc/raster/gpu_raster_buffer_provider.cc

Status: Fixed (was: Assigned)
Labels: Merge-Request-56
Status: Started (was: Fixed)
Cc: rbasuvula@chromium.org
 Issue 660339  has been merged into this issue.

Comment 21 by dimu@chromium.org, Jan 4 2017

Labels: -Merge-Request-56 Merge-Approved-56 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M56 (branch: 2924)
Your change has been approved for M56, please merged the CL ASAP.
Project Member

Comment 23 by sheriffbot@chromium.org, Jan 9 2017

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Needs-Triage-M54
Your change is approved for M56,  if all looks good please merge the CL ASAP.
We are planning to cut Beta RC today 01/10 at 4.00 PM PST.
Project Member

Comment 25 by sheriffbot@chromium.org, Jan 12 2017

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
Tested this issue on Mac 10.12.2 and Ubuntu 14.04 using latest canary #57.0.2982.0 as per comment #0.

Observed that the second line of text at 18px rendered a bit thin during the animation.

Attached a screencast for reference.

ericrk@ - Could you please verify the screen cast and please let us know if it is the expected behavior.

Thanks...!!
668723.ogv
2.7 MB View Download
Re #26, I believe this is working as expected - the 17 and 18 pt fonts appear to behave the same. I see what you mean (it looks a little thinner while animating), but this is much less extreme than what we were previously seeing.
Status: Fixed (was: Started)
Please merge the CL ASAP.We are planning to cut Beta RC today 01/17 at 4.00 PM PST.
Project Member

Comment 30 by bugdroid1@chromium.org, Jan 17 2017

Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/02e2db011add619c52509d0b1d42e85448062609

commit 02e2db011add619c52509d0b1d42e85448062609
Author: Eric Karl <ericrk@chromium.org>
Date: Tue Jan 17 19:48:37 2017

Don't use DF text during animations

Previously, we enabled distance-field text during animations in
order to improve GPU raster performance. Now that GPU raster
handles animations the same way as SW - only rastering at specific
scales and interpolating, this optimization isn't necessary.

In certain cases, the optimization causes visual differences
between non-animating and animating content, so removing this
improves our correctness as well.

R=ajuma@chromium.org
BUG= 668723 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2605273003
Cr-Commit-Position: refs/heads/master@{#441204}
(cherry picked from commit b04a4a62bc244a238e63c6862be0ed6dfe84a837)

Review-Url: https://codereview.chromium.org/2637223002 .
Cr-Commit-Position: refs/branch-heads/2924@{#783}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/02e2db011add619c52509d0b1d42e85448062609/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/02e2db011add619c52509d0b1d42e85448062609/cc/layers/picture_layer_impl_unittest.cc
[modify] https://crrev.com/02e2db011add619c52509d0b1d42e85448062609/cc/playback/raster_source.cc
[modify] https://crrev.com/02e2db011add619c52509d0b1d42e85448062609/cc/playback/raster_source.h
[modify] https://crrev.com/02e2db011add619c52509d0b1d42e85448062609/cc/raster/gpu_raster_buffer_provider.cc

Labels: -Needs-Feedback TE-Verified-M56 TE-Verified-56.0.2924.67
Verified this issue on Mac 10.12.2 & Ubuntu 14.04 using chrome latest beta M56-56.0.2924.67 by following steps mentioned in the original comment. Observed that Both lines of text appears the same font thickness during a CSS transform animation. Hence adding TE-Verified label.

Please find the screen cast for reference.

Thank you!
668723.mp4
476 KB View Download

Sign in to add a comment