Issue metadata
Sign in to add a comment
|
Transform is causing the text in that paragraph to render subpixel-antialiased (it repaints it)
Reported by
renandin...@gmail.com,
Dec 8 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 Steps to reproduce the problem: https://renandincer.com/next/index.html roughly speaking what's happening is that the transform is causing the text in that paragraph to render subpixel-antialiased (it repaints it) then when you hover your link that link gets repainted the rest of that paragraph doesn't get repainted because all that changed was the link why the aliasing is being switched is a bug but otherwise nothing here is that surprising repaints happen when things change that's very normal What is the expected behavior? What went wrong? fFr some reason the text becomes `antialiased` (not subpixel) Did this work before? N/A Does this work in other browsers? Yes Chrome version: 54.0.2840.98 Channel: n/a OS Version: OS X 10.12.1 Flash Version: Shockwave Flash 23.0 r0
,
Dec 9 2016
,
Dec 9 2016
I'm not seeing the issue here. On the displays I have, there's no subpixel-AA ever as far as I can tell. It is expected that text will drop subpixel-AA when there is a non-integer transform applied, because there is no sensible way to do sub-pixel AA when the text is not on an integer boundary. What is the subpixel-AA status when the page first loads? What is the subpixel-AA status when the box is hovered and transitions? What is the subpixel-AA status when a link is hovered? (How can you tell given we invert the text?) What is the subpixel-AA status when the link is un-hovered? What is the subpixel-AA status when the box is un-hovered and transitions back? Does the subpixel-AA status vary across different text runs? Exactly what machine are you running on? Of all the states I ask about above, which do you see as wrong?
,
Jan 3 2017
,
Jan 4 2017
Essentially, the issue is the following: Any text which is transitioned from an opacity <1 into 1 while also having translate3d applied will display heavier than normal. This jsFiddle does a good job demonstrating the underling issue: https://jsfiddle.net/ee8x0oos/show/light/ After the transition occurs, the first div appears much more bold than the other AA div, and even surprisingly more bold than the subpixel-AA div. Forcing a repaint fixes the issue. I had this issue on my website and I resolved it with the following: https://git.io/vM3TK As for machine, this is occurring for me on a mid-2015 rMBP, however I’ve seen it 2016 models as well.
,
Jan 4 2017
Meant to attach this to my previous comment.
,
Jan 4 2017
I can't see any problem with M56 or M57 on a Retina MacBook. The text in the fiddle looks identical. What Chrome version are you using for comment #5?
,
Jan 4 2017
Version 55.0.2883.95 (64-bit)
,
Jan 4 2017
Any chance you can install Chrome Canary (that can live beside an stable Chrome install without messing up your profiles)? We can then determine if the issue is fixed already.
,
Jan 4 2017
Just tried in Chrome Canary (Version 57.0.2971.0 canary (64-bit)) and it seems fixed.
,
Jan 4 2017
Thanks. We won't merge a fix like this back into M55. I'll leave the bug open until M56 hits the stable channel and we can verify there. Leaving the Unconfirmed label to simplify triage.
,
Jan 4 2017
Sounds good, thanks. Glad it’s already fixed in post-stable builds.
,
Feb 9 2017
At this point M56 has reached stable and the bug is fixed to our knowledge, though we don't know how. Re-open if M56 has the problem. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by erikc...@chromium.org
, Dec 9 2016Status: Untriaged (was: Unconfirmed)