Issue metadata
Sign in to add a comment
|
Fonts rendered too thin during transform CSS animation
Reported by
paul.ne...@gmail.com,
Nov 25 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: 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>
,
Nov 29 2016
,
Nov 30 2016
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...!!
,
Nov 30 2016
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
,
Dec 13 2016
ajuma@: Do you know if anything could have happened on CSS animation could that could be related to this?
,
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?
,
Dec 14 2016
,
Dec 15 2016
Here's a GIF of the issue - affects current Release & Canary builds, Mac, non-Retina display.
,
Dec 16 2016
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.
,
Dec 16 2016
,
Dec 16 2016
Just to update: Still able to reproduce the issue on Linux chrome version 57.0.2952.0
,
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.
,
Dec 19 2016
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,
,
Dec 27 2016
Re-assigning based on comment 9
,
Dec 30 2016
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?
,
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
,
Jan 3 2017
,
Jan 3 2017
,
Jan 3 2017
,
Jan 4 2017
,
Jan 4 2017
Your change meets the bar and is auto-approved for M56 (branch: 2924)
,
Jan 5 2017
Your change has been approved for M56, please merged the CL ASAP.
,
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
,
Jan 10 2017
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.
,
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
,
Jan 16 2017
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...!!
,
Jan 17 2017
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.
,
Jan 17 2017
,
Jan 17 2017
Please merge the CL ASAP.We are planning to cut Beta RC today 01/17 at 4.00 PM PST.
,
Jan 17 2017
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
,
Jan 18 2017
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! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Nov 25 2016