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

Issue 695362 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Flag #lcd-text-aa should have an effect independently of the system

Reported by balagema...@gmail.com, Feb 23 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. Go to chrome://flags and set #lcd-text-aa to Enabled.
2. Close Chrome (then make sure all instances were closed).
3. Turn off ClearType system-wide.
4. Start Chrome.

What is the expected behavior?
Flag setting for LCD text antialiasing (flag #lcd-text-aa) should be respected in a more logical way.

Default - Respect system-wide setting for ClearType
Enabled - Forcibly use DirectWrite with subpixel font smoothing (ignoring the system setting)
Disabled - Forcibly use DirectWrite with grayscale font smoothing (ignoring the system setting)

What went wrong?
If ClearType is turned off, Chrome performs grayscale rendering, ignoring the user setting for flag #lcd-text-aa.

DirectWrite Text rendering of Chrome produces a much better quality than any other part of the native Windows GUI. In some cases it would be the best to keep ClearType turned off while Chrome could deal with its own setting whether to use subpixel rendering or not. 

This must be possible to achieve and pretty easy to fix, as Chrome won't change its smoothing mode (subpixel/grayscale) once it is started. While other applications (e.g. Total Commander, Control Panel, etc.) immediately change their fonts when ClearType gets disabled, Chrome will keep its subpixel rendering until it's closed. For Chrome, it seems to be just a reading a setting when initializing DirectWrite.

Did this work before? No 

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 24.0 r0

 
Labels: Needs-Triage-M56
Cc: krajshree@chromium.org
Components: UI>Settings
Labels: Needs-Feedback
Unable to reproduce the issue on Win-10 using chrome reported version #56.0.2924.87 and latest canary #58.0.3027.0 .

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to chrome://flags and set #lcd-text-aa to Enabled.
2. Closed Chrome.
3. Turned off ClearType system-wide.
4. Started Chrome.

balagemayrag@ - Could you please check this issue on latest canary #58.0.3027.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

695362.mp4
7.8 MB View Download
First things first. Since GDI rendering was removed from Chrome for Windows, new DirectWrite font rendering behavior of Chrome is completely independent from the system-wide ClearType setting. Chrome will render using the method (subpixel/greyscale) it detects, once the browser is started. You have just verified this yourself in your screencast as you can see that the Chrome interface is not getting immediately affected by turning off ClearType while other Windows are.

I think we misunderstood each other. If you turn off ClearType and leave #lcd-text-aa Enabled, Chrome should display subpixel anti-aliased text because it should NOT respect the system setting when #lcd-text-aa is not set to Default.

I created a simple test matrix to show (attachment: lcd-aa-matrix.png) how it should work.

There are two cases when system-wide settings contradict #lcd-text-aa, case #3 and #5. In case #3 the system is set to subpixel rendering (ClearType enabled) but Chrome would still render grayscale fonts because #lcd-text-aa is set to Disabled. This is correct. In case #5 it's the opposite. The system is set to grayscale rendering (ClearType disabled) while #lcd-text-aa is set to Enabled. Chrome would NOT render its fonts using subpixel antialiasing, which is INCORRECT behavior.

I recorded two reproduction videos. One for case #3 and another for case #5. Case #5 is the one that needs a fix.
lcd-aa-matrix.png
78.9 KB View Download
case3pass.webm
6.4 MB View Download
case5fail.webm
7.2 MB View Download
Project Member

Comment 4 by sheriffbot@chromium.org, Mar 6 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: Blink>Fonts
Labels: -Type-Bug -Pri-2 -Needs-Triage-M56 M-59 Pri-1 Type-Bug-Regression
Owner: e...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 10 using chrome reported version #56.0.2924.87 and latest canary #59.0.3033.0.

Issue is specific to Windows-OS.

Bisect Information:
=====================
Good build: 51.0.2670.0  Revision(379497)

Bad Build : 51.0.2671.0  Revision(379691)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/e9f54102f094afa87dd22bdcbc26a5aec911e882..fcb65350f304fa26709868f426444255bef2e34e

From the above change log suspecting below change

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

eae@ - 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...!!

Comment 6 by e...@chromium.org, Mar 13 2017

Status: WontFix (was: Assigned)
Flags are not settings.
Chrome intentionally respects the system-wide ClearType settings and the system-wide font-smoothing settings.

We have no intention of supporting LCD font smoothing without ClearType.

Well, I'm sorry to hear that, especially for the following two reasons.

1. Google Chrome subpixel anti-aliasing works perfectly without enabling ClearType. This has already been proven, just see what happens if you disable ClearType while Chrome is running: the subpixel anti-aliased fonts will stay, with the same quality. This suggests that the rendering engine of Chrome smoothes its fonts independently of the system. That's why this behavior is even possible and an option overriding the system setting would be legitimate, if not mandatory. As "Grayscale with Cleartype enabled" is supported - and system setting ignored in this case - an opposite "Subpixel with Cleartype disabled" should also be made possible. The behavior now is kind of illogical anyways.

2. As I have already written, Chrome anti-aliasing performs its LCD text-smoothing way better than Windows does on native MFC controls (panels, menus, etc.). There is a lot of them in for example Windows 7. That's the reason why, in some cases, one might want to disable ClearType system-wide but enable it in Chrome.

I think your lack of intention should be reconsidered.

Sign in to add a comment