Closed Bug 814101 Opened 12 years ago Closed 12 years ago

Azure does not honor Windows cleartype setting, causing font issue in FF 17

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
17 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla20
Tracking Flags:
Tracking Status
firefox17 + verified
firefox18 + verified
firefox19 + verified
firefox-esr17 --- verified

People

(Reporter: Matt_G, Assigned: bas.schouten)

References

Details

(Keywords: regression)

Attachments

(7 files, 1 obsolete file)

Respect users system-wide cleartype setting v2
16.64 KB, patch
jfkthame
: review+
bas.schouten
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
Details | Diff | Splinter Review
Patch that applies to mozilla-release
16.39 KB, patch
Details | Diff | Splinter Review
Last resort patch that disables Azure content when cleartype is off
1.12 KB, patch
jfkthame
: review+
lsblakk
: approval-mozilla-release+
lsblakk
: approval-mozilla-esr17+
Details | Diff | Splinter Review
screenshot
161.50 KB, image/jpeg
Details
Result of Windows font smoothing setting
3.69 KB, image/png
Details
screenshot from ff18 with azure disabled and cleartype off
4.63 KB, image/png
Details
screenshot from ff18 with gfx.direct2d.disabled=true
4.15 KB, image/png
Details 
We are seeing a lot of complaints about font issues in FF 17 on the SUMO Forums:
https://support.mozilla.org/en-US/questions/942265

Turning off HA only works for some users. We aren't seeing any trends in GFX cards or drivers. It does seem to be Windows only. I've already received email addresses from 3 users willing to help with 1 on 1 troubleshooting.
tracking-firefox17: --- → ?
https://bug777089.bugzilla.mozilla.org/attachment.cgi?id=650985 is mentioned that has the pref font.size.inflation.mappingIntercept
Setting the integer for the option above (font.size.inflation.mappingIntercept) does nothing at all.
(In reply to Ian C from comment #3)
> Setting the integer for the option above
> (font.size.inflation.mappingIntercept) does nothing at all.

As in, setting it to zero or one, has the same effect. Quite a useless option.
I don't think bug 777089 (the font.size.inflation.mappingIntercept pref) is relevant to this at all.

Adding Roc to cc list. It looks like people are getting ClearType (with bad gamma?) in UI elements such as the URL bar and tab titles now, where they were getting non-antialiased text in FF16. Is this an expected change? Did something change in layer compositing that would cause this?
Flags: needinfo?(roc)
Tracking - we should find out what, if anything, regressed here so we can evaluate our options.
tracking-firefox17: ? → +
There are also some comments that disabling hardware acceleration has an effect (although we can't find anything similar in users' graphics cards/drivers).
(In reply to Jonathan Kew (:jfkthame) from comment #5)
> Adding Roc to cc list. It looks like people are getting ClearType (with bad
> gamma?) in UI elements such as the URL bar and tab titles now, where they
> were getting non-antialiased text in FF16. Is this an expected change? Did
> something change in layer compositing that would cause this?

I don't remember anything specific. We've always tried to have subpixel-AA text in the chrome so I'm kind of surprised to hear that that's being seen as a regression. If anything did change, it wouldn't be in layer compositing I think, but either in FrameLayerBuilder or in the chrome DOM/style.

Alice might be able to tell us what changed when, if she can reproduce it.
Flags: needinfo?(roc)
"Bad gamma" for D2D-drawn text is a problem, though, and I wish we had a better solution for it.
Looks like this is an Azure issue.

In FF16 (and earlier), gfx.content.azure.enabled was set to false (see bug 769993), even though it had been turned on in bug 715768, so most users didn't see the problem. But in FF17, it's set to true.

With azure content enabled, Firefox uses subpixel font rendering throughout chrome and content, regardless of whether ClearType is enabled or disabled in the Windows control panel. This problem didn't occur when azure content was turned off.

I've heard back from one (so far) of the users reporting this via SUMO, confirming that setting gfx.content.azure.enabled back to false resolves the issue.

I think this is a serious Azure bug - our rendering should respect the user's choice in the Windows control panel. Until that is fixed, I think we should disable azure content again. And given the level of user complaints, we should consider pushing out a 17.0.1 update that flips the pref; we can't expect every user who dislikes ClearType to search out this solution and flip it manually.

BTW, at one point we had the same issue with non-Azure D2D content using subpixel AA even when ClearType was preffed off in Windows. This was fixed in bug 719410, but it seems Azure needs a similar fix.
Blocks: 715768
Keywords: regression
(In reply to Jonathan Kew (:jfkthame) from comment #10)
> Looks like this is an Azure issue.
> 
> In FF16 (and earlier), gfx.content.azure.enabled was set to false (see bug
> 769993), even though it had been turned on in bug 715768, so most users
> didn't see the problem. But in FF17, it's set to true.
> 
> With azure content enabled, Firefox uses subpixel font rendering throughout
> chrome and content, regardless of whether ClearType is enabled or disabled
> in the Windows control panel. This problem didn't occur when azure content
> was turned off.
> 
> I've heard back from one (so far) of the users reporting this via SUMO,
> confirming that setting gfx.content.azure.enabled back to false resolves the
> issue.
> 
> I think this is a serious Azure bug - our rendering should respect the
> user's choice in the Windows control panel. Until that is fixed, I think we
> should disable azure content again. And given the level of user complaints,
> we should consider pushing out a 17.0.1 update that flips the pref; we can't
> expect every user who dislikes ClearType to search out this solution and
> flip it manually.
> 
> BTW, at one point we had the same issue with non-Azure D2D content using
> subpixel AA even when ClearType was preffed off in Windows. This was fixed
> in bug 719410, but it seems Azure needs a similar fix.

It's trivial for -us- to flip the pref only if a user has cleartype set to false in the control panel, that seems like a better fix. But in any case, Azure content -should- be respecting the pref, I'll look into why it's not.
We do indeed not respect the system cleartype pref. I'll have a patch for the issue up in a little bit. I'm not sure whether this is important enough for a 17.0.1, I'll also add code that disables Azure content if system wide font smoothing is disabled, which would be a 'slightly' less risky alternative. Although I doubt the proper fix will be very risky.
This patch makes Azure respect the user's system-wide cleartype setting.
Attachment #684407 - Flags: review?(jmuizelaar)
Attachment #684407 - Flags: review?(jmuizelaar) → review+
Comment on attachment 684407 [details] [diff] [review]
Respect users system-wide cleartype setting

Review of attachment 684407 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/2d/ScaledFontDWrite.cpp
@@ +174,5 @@
> +{
> +  return *(unsigned short*)aBuf;
> +}
> +
> +// This code depends on our platform being Big Endian!

This sounds like a problem! Last I knew, x86 was LITTLE endian...

@@ +200,5 @@
> +      return true;
> +    }
> +    gaspRange *ranges = (gaspRange *)(tableData + 4);
> +    for (int i = 0; i < numRanges; i++) {
> +      if (ranges[i].maxPPEM > ppem) {

...which means I don't believe this will work correctly.

@@ +201,5 @@
> +    }
> +    gaspRange *ranges = (gaspRange *)(tableData + 4);
> +    for (int i = 0; i < numRanges; i++) {
> +      if (ranges[i].maxPPEM > ppem) {
> +        if (!(ranges[i].behavior & GASP_DOGRAY)) {

Nor this.
Attachment #684407 - Flags: review-
Component: General → Graphics
Product: Firefox → Core
(In reply to Jonathan Kew (:jfkthame) from comment #14)
> Comment on attachment 684407 [details] [diff] [review]
> Respect users system-wide cleartype setting
> 
> Review of attachment 684407 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/2d/ScaledFontDWrite.cpp
> @@ +174,5 @@
> > +{
> > +  return *(unsigned short*)aBuf;
> > +}
> > +
> > +// This code depends on our platform being Big Endian!
> 
> This sounds like a problem! Last I knew, x86 was LITTLE endian...
> 
> @@ +200,5 @@
> > +      return true;
> > +    }
> > +    gaspRange *ranges = (gaspRange *)(tableData + 4);
> > +    for (int i = 0; i < numRanges; i++) {
> > +      if (ranges[i].maxPPEM > ppem) {
> 
> ...which means I don't believe this will work correctly.
> 
> @@ +201,5 @@
> > +    }
> > +    gaspRange *ranges = (gaspRange *)(tableData + 4);
> > +    for (int i = 0; i < numRanges; i++) {
> > +      if (ranges[i].maxPPEM > ppem) {
> > +        if (!(ranges[i].behavior & GASP_DOGRAY)) {
> 
> Nor this.

You are obviously, absolutely right. Fixed.
Fixed endianness conversion.
Attachment #684407 - Attachment is obsolete: true
Attachment #684496 - Flags: review?(jfkthame)
Comment on attachment 684496 [details] [diff] [review]
Respect users system-wide cleartype setting v2

Carrying r+ from jrmuizel
Attachment #684496 - Flags: review+
Comment on attachment 684496 [details] [diff] [review]
Respect users system-wide cleartype setting v2

Review of attachment 684496 [details] [diff] [review]:
-----------------------------------------------------------------

Looks much better, thanks! :)  A few minor nits/suggestions below.

::: gfx/2d/2D.h
@@ +72,5 @@
>    {}
>  
>    Float mAlpha;
>    CompositionOp mCompositionOp : 8;
> +  AntialiasMode mAntialiasMode : 3;

AFAICS, this still only needs 2 bits, doesn't it? Possible values are 0-3.

::: gfx/2d/DrawTargetD2D.cpp
@@ +919,5 @@
>    ID2D1RenderTarget *rt = GetRTForOperation(aOptions.mCompositionOp, aPattern);
>  
>    PrepareForDrawing(rt);
>  
> +  D2D1_TEXT_ANTIALIAS_MODE d2dAAMode = D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE;

It's redundant to initialize this here, as the switch handles all cases. (And it would seem most logical to initialize to DEFAULT, if anything, though it makes no difference in the end.)

::: gfx/2d/ScaledFontDWrite.cpp
@@ +145,5 @@
> +{
> +  BOOL font_smoothing;
> +  UINT smoothing_type;
> +
> +  if (!SystemParametersInfo (SPI_GETFONTSMOOTHING, 0, &font_smoothing, 0)) {

Our style doesn't normally use a space before the parens for a function call, I think.

@@ +151,5 @@
> +  }
> +
> +  if (font_smoothing) {
> +      if (!SystemParametersInfo (SPI_GETFONTSMOOTHINGTYPE,
> +                                 0, &smoothing_type, 0)) {

Same here.

@@ +179,5 @@
> +static inline unsigned short
> +readShort(const char *aBuf)
> +{
> +  return reverseEndian(*(unsigned short*)aBuf);
> +}

I'd be happier if this were written in an endian-independent way - e.g. something like

readShort(const uint8_t *aBuf)
{
  return (*aBuf << 8) | *(aBuf + 1);
}

@@ +207,5 @@
> +    }
> +    gaspRange *ranges = (gaspRange *)(tableData + 4);
> +    for (int i = 0; i < numRanges; i++) {
> +      if (reverseEndian(ranges[i].maxPPEM) > ppem) {
> +        if (!(reverseEndian(ranges[i].behavior) & GASP_DOGRAY)) {

And then you could use readShort to access these fields in an endian-independent way as well.
Attachment #684496 - Flags: review?(jfkthame) → review+
(In reply to Jonathan Kew (:jfkthame) from comment #19)
> Comment on attachment 684496 [details] [diff] [review]
> Respect users system-wide cleartype setting v2
> 
> Review of attachment 684496 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks much better, thanks! :)  A few minor nits/suggestions below.
> 
> ::: gfx/2d/2D.h
> @@ +72,5 @@
> >    {}
> >  
> >    Float mAlpha;
> >    CompositionOp mCompositionOp : 8;
> > +  AntialiasMode mAntialiasMode : 3;
> 
> AFAICS, this still only needs 2 bits, doesn't it? Possible values are 0-3.

Enums are signed I think. I tried just to test with 2 and it gives -1 for AA_DEFAULT.
https://hg.mozilla.org/mozilla-central/rev/72537442896d
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Will the bug be backout to 17?
(In reply to xunxun from comment #23)
> Will the bug be backout to 17?

I don't think it should be.
(In reply to Bas Schouten (:bas.schouten) from comment #24)
> (In reply to xunxun from comment #23)
> > Will the bug be backout to 17?
> 
> I don't think it should be.

Why? Does the bug not affect Fx17?
(In reply to Bas Schouten (:bas.schouten) from comment #24)
> (In reply to xunxun from comment #23)
> > Will the bug be backout to 17?
> 
> I don't think it should be.

Really? I disagree. JP said this is "the #1 support issue for FF17"; it's clearly affecting a substantial number of users, and it's a serious visual regression for them.

If we don't backport this to 17.0.1 - assuming there's going to be one - on the grounds that it may be too risky/invasive (I notice that the patch doesn't apply on mozilla-release; it has about 10 failed hunks), then I think we should turn off the content.azure pref. We already did that for FF15 and FF16 in bug 769993; it would be better to do so again for one more cycle than to continue shipping with this regression.
(In reply to Jonathan Kew (:jfkthame) from comment #26)
> (In reply to Bas Schouten (:bas.schouten) from comment #24)
> > (In reply to xunxun from comment #23)
> > > Will the bug be backout to 17?
> > 
> > I don't think it should be.
> 
> Really? I disagree. JP said this is "the #1 support issue for FF17"; it's
> clearly affecting a substantial number of users, and it's a serious visual
> regression for them.
> 
> If we don't backport this to 17.0.1 - assuming there's going to be one - on
> the grounds that it may be too risky/invasive (I notice that the patch
> doesn't apply on mozilla-release; it has about 10 failed hunks), then I
> think we should turn off the content.azure pref. We already did that for
> FF15 and FF16 in bug 769993; it would be better to do so again for one more
> cycle than to continue shipping with this regression.

If there -is- going to be a 17.0.1 I'm all for backporting it. And I'm more than happy to make a patch that applies to mozilla-release.

However, this ran on Beta for 6 weeks shipping to over a million people, and we didn't notice any bugs with relation to this. This makes me think that the people suffering from this bug are loud, rather than that they exist in large numbers (otherwise one would statistically expect them to show up on the beta channel as well).

Azure content offers a number of substantial performance improvements in FF17 (for example browser chrome on slow machines), that weren't there yet in 15 and 16. I'd be hesitant to ship a perf regression to 25% of our userbase based on an unknown(but presumably small) number of people suffering from a perceived visual quality reduction.

Having said that, as I've said before there's an easy compromise, if we judge this patch too invasive for mozilla-release, and we judge the problem seriously enough to address in a 17.0.1, I can make a simple patch that disables Azure content for people having switched off cleartype. That way the performance regression would only affect people who are suffering from the visual quality 'regression'.
And btw, the patch is not compatible with Fx17 (ScaledFontDWrite.cpp)
(In reply to Bas Schouten (:bas.schouten) from comment #27)
> Having said that, as I've said before there's an easy compromise, if we
> judge this patch too invasive for mozilla-release, and we judge the problem
> seriously enough to address in a 17.0.1, I can make a simple patch that
> disables Azure content for people having switched off cleartype. That way
> the performance regression would only affect people who are suffering from
> the visual quality 'regression'.

I think it'd be good to go ahead and prepare such a patch, so that release drivers can see exactly what our options are, how invasive the code changes look, etc., and then make the final call on what to do here.
Comment on attachment 684724 [details] [diff] [review]
Last resort patch that disables Azure content when cleartype is off

Review of attachment 684724 [details] [diff] [review]:
-----------------------------------------------------------------

Do we need to think about how dynamic changes work? It looks like if ClearType is disabled, this won't cache the state, but re-check every time UseAzureContentDrawing() is called. But if ClearType is enabled - even momentarily - it'll read the pref and cache that, and then it won't notice if CT is turned off again. That seems a bit inconsistent/confusing. Does it matter if the result of UseAzureContentDrawing() changes during the session - do we support on-the-fly changes?
(In reply to Jonathan Kew (:jfkthame) from comment #32)
> Comment on attachment 684724 [details] [diff] [review]
> Last resort patch that disables Azure content when cleartype is off
> 
> Review of attachment 684724 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Do we need to think about how dynamic changes work? It looks like if
> ClearType is disabled, this won't cache the state, but re-check every time
> UseAzureContentDrawing() is called. But if ClearType is enabled - even
> momentarily - it'll read the pref and cache that, and then it won't notice
> if CT is turned off again. That seems a bit inconsistent/confusing. Does it
> matter if the result of UseAzureContentDrawing() changes during the session
> - do we support on-the-fly changes?

On the fly change is supported from going -off- to -on- only, not the other way around. In any case consider how hard it is to change the cleartype setting, and how few people do it, I don't think it's going to batter. I also highly doubt a lot of people will be flipping the pref while running firefox, and if they do, well they can restart I'm sure. I don't think it's worth putting a lot of effort into doing anything more complicated than this patch.
(In reply to Bas Schouten (:bas.schouten) from comment #33)

> On the fly change is supported from going -off- to -on- only, not the other
> way around. In any case consider how hard it is to change the cleartype
> setting, and how few people do it, I don't think it's going to batter. I
> also highly doubt a lot of people will be flipping the pref while running
> firefox, and if they do, well they can restart I'm sure. I don't think it's
> worth putting a lot of effort into doing anything more complicated than this
> patch.

OK, I can live with that - just wanted to make sure we understand what is and isn't being supported here.
Attachment #684724 - Flags: review?(jfkthame) → review+
(In reply to Bas Schouten (:bas.schouten) from comment #30)
> Created attachment 684721 [details] [diff] [review]
> Patch that applies to mozilla-release

OK, I will build it myself and wait for 17.0.1 :)
Is TB17 suffering from the same issue? At least I can see colored shadow around the text. Here's an example with azure off and on
https://www.box.com/s/x3xrs5ps0rwm1ge3ixek
Yes - it's a bug in the Gecko platform, so I'd expect it to affect TB as well as FF.
For FF17, couldn't the simple pref flip be taken care of by an Add-On Hotfix instead of a new release?
(In reply to Kelley Cook from comment #39)
> For FF17, couldn't the simple pref flip be taken care of by an Add-On Hotfix
> instead of a new release?

Perhaps, but we'd still be regressing a large group of users which don't actually switch off cleartype.
If we ship a point release for 17, we should get the "last resort" patch into that release. What kind of testing or other confidence building measures do we need to feel good about taking this into a release?
If a person is capable of switching off ClearType, can't he also be expected to manually download a Firefox chemspill release that isn't shipped as an automatic update?
Comment on attachment 684496 [details] [diff] [review]
Respect users system-wide cleartype setting v2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 715768 (Azure content rendering); masked on release until FF17 because this was preffed off in bug 769993.

User impact if declined: Users with ClearType turned off system-wide in Windows are unhappy because they see blurry/color-fringed fonts in Firefox

Testing completed (on m-c, etc.): Running m-c nightlies on Win7 with cleartype disabled confirms that the issue is fixed as of 2012-11-23.

Risk to taking this patch (and alternatives if risky): Pretty low risk - should only affect Windows users who have ClearType disabled, and only alters the font antialiasing mode. Alternative workaround for affected users is to disable Azure content rendering, but this is hidden in about:config - most users will not find it - and may regress performance.

String or UUID changes made by this patch: none
Attachment #684496 - Flags: approval-mozilla-beta?
Attachment #684496 - Flags: approval-mozilla-aurora?
Comment on attachment 684496 [details] [diff] [review]
Respect users system-wide cleartype setting v2

[Triage Comment]
Approving for branches in preparation for possible inclusion in a FF17.0.1 release, which is TBD.
Attachment #684496 - Flags: approval-mozilla-beta?
Attachment #684496 - Flags: approval-mozilla-beta+
Attachment #684496 - Flags: approval-mozilla-aurora?
Attachment #684496 - Flags: approval-mozilla-aurora+
When this has been verified on aurora/beta builds, we'll want nominations for mozilla-release and mozilla-esr17 landings as well since we're aiming to get this into our 17.0.1 build this week.
For mozilla-release (and mozilla-esr17?), are we going to take the backported version of the main Azure patch here (recognizing that it's had to be rebased from the version on trunk/aurora/beta, though AFAIK it should be equivalent in effect), or the smaller/less-invasive "last resort" patch that simply disables the azure-content pref for affected users?

FWIW, I pushed a tryserver build of mozilla-release + the last-resort patch, just to check that it didn't throw up surprises:
https://tbpl.mozilla.org/?tree=Try&rev=dd0b9837b877
Sorry for not being more specific. Let's take the less risky, less invasive "last resort" patch to release/esr17 and let the full version bake on beta for a few more weeks.  For the ESR though, this will be their only patch for this issue since the follow up won't be uplifted to future ESR versions - do you forsee any problems with that? I'm assuming this issue will not be a major one for ESR deployments, but please correct me if I could be wrong here.
(In reply to Lukas Blakk [:lsblakk] from comment #49)
> Sorry for not being more specific. Let's take the less risky, less invasive
> "last resort" patch to release/esr17 and let the full version bake on beta
> for a few more weeks.  For the ESR though, this will be their only patch for
> this issue since the follow up won't be uplifted to future ESR versions - do
> you forsee any problems with that?

I don't think so. It means that Windows ESR users who have ClearType disabled will not benefit from possible performance improvements that Azure content offers, but I think that's acceptable. ESR users are by definition not seeking to be on the bleeding edge of performance work anyway.

> I'm assuming this issue will not be a
> major one for ESR deployments, but please correct me if I could be wrong
> here.

I'm guessing - with no evidence whatsoever to back it up! - the basic issue here might, if anything, be more common among ESR users than the population as a whole. That's based on the supposition that there could be some correlation between disabling ClearType and using ESR. (Why? Both seem like possible characteristics of a general attitude or environment of "software conservatism".)

This could also be why we didn't hear a lot of noise about this during Aurora/Beta (comment 27): those user populations are likely to be adventurous "power user" types, who may be the least likely to take a "keep-things-the-way-they've-always-been" step such as disabling ClearType. So it's only when the issue hits the release channel that those more conservative users see it.

Anyway, as long as we get the simple patch into ESR so that CT-disabled users don't have subpixel-AA forced on them, I think we're fine.
Comment on attachment 684724 [details] [diff] [review]
Last resort patch that disables Azure content when cleartype is off

[Approval Request Comment]
Regression caused by (bug #): 715768 (azure content)

User impact if declined:
Users who have explicitly disabled ClearType system-wide in Windows will see undesired subpixel AA on text in Firefox.

Testing completed (on m-c, etc.):
Confirmed locally that the try build (comment 48) behaves as expected on Win7 with ClearType disabled (does not use subpixel AA), and with CT enabled (renders subpixel AA as usual).

Risk to taking this patch (and alternatives if risky):
Risk seems minimal - the patch just checks the Windows setting and uses it to override the azure-content pref, reverting to pre-FF17 behavior in this case. Alternatives - the full patch above, which makes azure correctly respect the system setting (but is much larger/more invasive/higher risk); or unconditionally reverting the azure-content pref, as was done for FF15/16 in bug 769993 (minimal risk of introducing new issues, as it would just revert to using pre-existing code, but risks losing perf improvements for users who are not affected by this issue).
Attachment #684724 - Flags: approval-mozilla-release?
Attachment #684724 - Flags: approval-mozilla-esr17?
Comment on attachment 684724 [details] [diff] [review]
Last resort patch that disables Azure content when cleartype is off

Too lazy to go back and see if I mentioned already - the esr17 landings need to go on default and relbranch GECKO170_2012111914_RELBRANCH
Attachment #684724 - Flags: approval-mozilla-release?
Attachment #684724 - Flags: approval-mozilla-release+
Attachment #684724 - Flags: approval-mozilla-esr17?
Attachment #684724 - Flags: approval-mozilla-esr17+
QA Contact: anthony.s.hughes
I've asked Marcia to do some testing around this fix this morning.
QA Contact: anthony.s.hughes → mozillamarcia.knous
Jonathan: I have been asked to test around and verify this fix - what kinds of things should I be on the lookout for?  Also I assume this is something we want to test on real hardware versus a VM?
The key issue here is that some users dislike ClearType (subpixel) antialiasing, because they feel it makes the fonts heavier or blurrier or gives too much color-fringing. So they turn it off system-wide in the Windows control panel.

The bug in the FF17 release is that the browser continues to use subpixel (ClearType) rendering even when the user has turned it off in Windows.

So what you need to verify is that the fixed version behaves correctly in both ClearType-enabled and -disabled environments; the former *should* use subpixel rendering, the latter must *not*. For the "last resort" patch, intended for 17.0.1, you'll need to restart the browser after changing the Windows setting in order to confirm the behavior - it doesn't necessarily handle on-the-fly changes.

Depending on your screen (and your eyes!) it may or may not be easy to tell the difference at a glance; using the Windows Magnifier tool lets you examine the text more closely to verify how it's rendering.
I can verify using Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0 (beta 2), the latest nightly and the latest Aurora builds that the ClearType pref is honored when it is turned on and off. I used http://www.lagom.nl/lcd-test/subpixel.php as the reference site when I was testing. I was testing in a Win 7 Pro VM.
Thank you Marcia. Flagging this for verification once we have 17.0.1 builds.
Keywords: verifyme
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #57)
> Thank you Marcia. Flagging this for verification once we have 17.0.1 builds.

Really? I find it highly unlikely that on a Virtual Machine Direct2D is getting enabled! Please check the graphics section of about:support. This bug will -only- occur with Direct2D/D3D10 layers enabled.
Marcia, are you able to follow-up here with some native environment testing?
(In reply to Bas Schouten (:bas.schouten) from comment #58)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #57)
> > Thank you Marcia. Flagging this for verification once we have 17.0.1 builds.
> 
> Really? I find it highly unlikely that on a Virtual Machine Direct2D is
> getting enabled! Please check the graphics section of about:support. This
> bug will -only- occur with Direct2D/D3D10 layers enabled.

Right - sorry I didn't point out that aspect of it. To confirm your environment is appropriate for testing (besides checking about:support for Direct2D/D3D10), you could check that Firefox 17.0 *does* (inappropriately) do subpixel antialiasing even when ClearType is turned off. That's the bug that you should see in 17.0, but not in 18.0 or later.
Testing with NVidia GeForce 8600GT.

Firefox 17.0
 * Direct2D enabled = true
 * layers.acceleration.disabled = false
 * GPU Accelerated Windows = 1/1 Direct3D 10
 * ClearType Parameters = not found
Flipping Control Panel > Appearance > Display > ClearType on/off I can see the changes in Firefox 17.0. It would appear, at least for me I can't reproduce this bug.

Please advise.
(In reply to Jonathan Kew (:jfkthame) from comment #61)
> Pushed to mozilla-release for 17.0.1:
> https://hg.mozilla.org/releases/mozilla-release/rev/cae7a6c101e0

And a followup, because right after I pushed it, I realized it was going to burn everywhere except Windows. :(
https://hg.mozilla.org/releases/mozilla-release/rev/ceeb26d2e254
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #62)
> Testing with NVidia GeForce 8600GT.
> 
> Firefox 17.0
>  * Direct2D enabled = true
>  * layers.acceleration.disabled = false
>  * GPU Accelerated Windows = 1/1 Direct3D 10
>  * ClearType Parameters = not found
> Flipping Control Panel > Appearance > Display > ClearType on/off I can see
> the changes in Firefox 17.0. It would appear, at least for me I can't
> reproduce this bug.
> 
> Please advise.

Have you manually toggled gfx.azure.content.enabled ?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #62)
> Testing with NVidia GeForce 8600GT.
> 
> Firefox 17.0
>  * Direct2D enabled = true
>  * layers.acceleration.disabled = false
>  * GPU Accelerated Windows = 1/1 Direct3D 10
>  * ClearType Parameters = not found
> Flipping Control Panel > Appearance > Display > ClearType on/off I can see
> the changes in Firefox 17.0. It would appear, at least for me I can't
> reproduce this bug.
> 
> Please advise.

Seems odd; I can definitely reproduce here with 17.0.

You don't happen to have gfx.content.azure.enabled set to false, do you? That would prevent seeing the bug.

Note that flipping the ClearType setting while Firefox is running will often cause a slight (but distinctly visible) change as glyph spacing/positioning gets adjusted, but the antialiasing may still not be correct. Try using the Windows Magnifier to inspect the text in the URL bar, and check whether it's strictly grayscale-only when ClearType is disabled.
Yes, I did ask whether a VM was suitable for testing, and apparently it turns out it is not - sorry but I did not get a clear answer when I asked in Comment 54.

(In reply to Bas Schouten (:bas.schouten) from comment #58)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #57)
> > Thank you Marcia. Flagging this for verification once we have 17.0.1 builds.
> 
> Really? I find it highly unlikely that on a Virtual Machine Direct2D is
> getting enabled! Please check the graphics section of about:support. This
> bug will -only- occur with Direct2D/D3D10 layers enabled.
(In reply to Jonathan Kew (:jfkthame) from comment #65)
> (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #62)
> > Testing with NVidia GeForce 8600GT.
> > 
> > Firefox 17.0
> >  * Direct2D enabled = true
> >  * layers.acceleration.disabled = false
> >  * GPU Accelerated Windows = 1/1 Direct3D 10
> >  * ClearType Parameters = not found
> > Flipping Control Panel > Appearance > Display > ClearType on/off I can see
> > the changes in Firefox 17.0. It would appear, at least for me I can't
> > reproduce this bug.
> > 
> > Please advise.
> 
> Seems odd; I can definitely reproduce here with 17.0.
> 
> You don't happen to have gfx.content.azure.enabled set to false, do you?
> That would prevent seeing the bug.

Nope, it's true.

> Note that flipping the ClearType setting while Firefox is running will often
> cause a slight (but distinctly visible) change as glyph spacing/positioning
> gets adjusted, but the antialiasing may still not be correct. Try using the
> Windows Magnifier to inspect the text in the URL bar, and check whether it's
> strictly grayscale-only when ClearType is disabled.

Okay, I can see the difference now. With cleartype on, 20.0a1 and 17.0 text is blurred at 500% zoom. With cleartype off, 17.0 is still blurred (but looks a bit different) while 20.0a1 is not blurred at all. I think we can call this fixed enough for release. We'll do more testing when we have 17.0.1 candidates.

I will check Aurora and Beta now.
2012-11-28 Firefox 19.0a2 and Firefox 18.0b2#1 builds respect the cleartype pref.
status-firefox18: fixed → verified
status-firefox19: fixed → verified
Why https://bugzilla.mozilla.org/attachment.cgi?id=684721 is not merged to 17 branch?
I wasn't able to reproduce the initial problem on FF 17 on Win 7 32/64, Win 8 32/64 both with NVIDIA/ATI cards. Same behavior on FF 17.0.1.
https://wiki.mozilla.org/Releases/Firefox_17/Test_Plan#bug_814101_Font_Issue_in_FF_17
(In reply to Paul Silaghi [QA] from comment #71)
> I wasn't able to reproduce the initial problem on FF 17 on Win 7 32/64, Win
> 8 32/64 both with NVIDIA/ATI cards. Same behavior on FF 17.0.1.
> https://wiki.mozilla.org/Releases/Firefox_17/
> Test_Plan#bug_814101_Font_Issue_in_FF_17

Note that you should be checking for -subpixel- Anti-aliased text. You will always get anti-aliased text. What you need to check for with the magnifier is whether the edge pixels of glyphs have pixels which are 'colored'.
Attached image screenshot — 
(In reply to Bas Schouten (:bas.schouten) from comment #72)
> (In reply to Paul Silaghi [QA] from comment #71)
> > I wasn't able to reproduce the initial problem on FF 17 on Win 7 32/64, Win
> > 8 32/64 both with NVIDIA/ATI cards. Same behavior on FF 17.0.1.
> > https://wiki.mozilla.org/Releases/Firefox_17/
> > Test_Plan#bug_814101_Font_Issue_in_FF_17
> 
> Note that you should be checking for -subpixel- Anti-aliased text. You will
> always get anti-aliased text. What you need to check for with the magnifier
> is whether the edge pixels of glyphs have pixels which are 'colored'.

I can see 'colored' pixels at the edges, on both Firefox 17.0 and 17.0.1, Win 8,  AMD Radeon HD 6450 card. 

See attached screenshot (Clear Type on)
(In reply to Mihaela Velimiroviciu [QA] (:mihaela) from comment #73)
> Created attachment 686566 [details]
> screenshot
> 
> (In reply to Bas Schouten (:bas.schouten) from comment #72)
> > (In reply to Paul Silaghi [QA] from comment #71)
> > > I wasn't able to reproduce the initial problem on FF 17 on Win 7 32/64, Win
> > > 8 32/64 both with NVIDIA/ATI cards. Same behavior on FF 17.0.1.
> > > https://wiki.mozilla.org/Releases/Firefox_17/
> > > Test_Plan#bug_814101_Font_Issue_in_FF_17
> > 
> > Note that you should be checking for -subpixel- Anti-aliased text. You will
> > always get anti-aliased text. What you need to check for with the magnifier
> > is whether the edge pixels of glyphs have pixels which are 'colored'.
> 
> I can see 'colored' pixels at the edges, on both Firefox 17.0 and 17.0.1,
> Win 8,  AMD Radeon HD 6450 card. 
> 
> See attached screenshot (Clear Type on)

Right, now with FF17.0.1, these should disappear when you restart Firefox after turning off ClearType in the control panel. In FF17 these should -not- disappear. That's what we're verifying here :).
(In reply to Paul Silaghi [QA] from comment #71)
> I wasn't able to reproduce the initial problem on FF 17 on Win 7 32/64, Win
> 8 32/64 both with NVIDIA/ATI cards. Same behavior on FF 17.0.1.
> https://wiki.mozilla.org/Releases/Firefox_17/
> Test_Plan#bug_814101_Font_Issue_in_FF_17

Thanks for clearing things up Bas!
Verified fixed on FF 17.0.1 based on comment 74.
status-firefox17: fixed → verified
May I interrupt you and ask a probably stupid question? Because I don't understand one thing here. Enlighten me. How is that you guys have to use magnifier to see it? For me it's like night and day.
You can't tell the difference between this
(FF16) http://i46.tinypic.com/qmxkq8.png and this
(FF17) http://i50.tinypic.com/2qkm9up.png ?
Or is it obvious on those screenshots, but for some reason it looks different on your end?
This has now been verified fixed in Firefox 17.0.1esr candidates, and with that across all branches.
Status: RESOLVED → VERIFIED
status-firefox-esr17: fixed → verified
Keywords: verifyme
(In reply to Guniu from comment #76)
> May I interrupt you and ask a probably stupid question? Because I don't
> understand one thing here. Enlighten me. How is that you guys have to use
> magnifier to see it? For me it's like night and day.
> You can't tell the difference between this
> (FF16) http://i46.tinypic.com/qmxkq8.png and this
> (FF17) http://i50.tinypic.com/2qkm9up.png ?
> Or is it obvious on those screenshots, but for some reason it looks
> different on your end?

These do not look like the default fonts in most locales. In this case without subpixel AA (i.e. 16), you don't get anti-aliasing at all, which causes the jagged look on glyphs, that's what makes it so obvious in this font. In the standard font used in most places the difference is only between grayscale AA and subpixel AA.
(In reply to Bas Schouten (:bas.schouten) from comment #78)
> These do not look like the default fonts in most locales. In this case
> without subpixel AA (i.e. 16), you don't get anti-aliasing at all, which
> causes the jagged look on glyphs, that's what makes it so obvious in this
> font. In the standard font used in most places the difference is only
> between grayscale AA and subpixel AA.

Oh, that's probably because I changed fonts in Windows to Tahoma instead of Segoe UI. I didn't know they apply to Firefox too.
Thank you for explanation.
17.0.1 is still having the font problem for me, so I set gfx.content.azure.enabled = False again. Is the 17.0.1 fix different from the fix that will be in 18.0, because I have no problem waiting for 18.0 to see if it is truly fixed, and am fine with the about:config work-around until then.
17.0.1 introduced a regression as far as I'm concerned; my FF UI text (tab titles, address bar, search bar etc.) suddenly became blurry. I did not have any problems with 17.0.

ClearType is enabled in my control panel. General UI font is Segoe UI, defaults for Windows 7 etc.

Setting gfx.content.azure.enabled to false fixed the blurriness for now.

Windows Key + / - zoom verified that subpixel aliasing is still in effect. With azure.enabled set to true, Firefox UI text rendering looked dirty and clumpy like WPF .net apps.
The 17.0.1 fix does NOT work.

It still renders blurry fonts on Windows 7 with ClearType disabled. Setting the gfx.content.azure.enabled to false also does NOT help. The only workaround is to disable HW acceleration.

Please introduce a setting that will turn the blurry fonts off FOREVER, as it was in 16.0 version.
(In reply to Barry Kelly from comment #81)
> ClearType is enabled in my control panel.
> Windows Key + / - zoom verified that subpixel aliasing is still in effect.

Isn't that the expected outcome then? You previously had no AA at all or greyscale AA?
I might have the explanation; it's kind of strange but tests this:
Windows have two setting for font smoothing:
-The Cleartype tuner found in the control panel
-A checkbox in System > Advance system settings > Default Tab > Performance Setting > A checkbox named "Smooth edges of screen fonts"

See attachment to see what is what and the result.

The only wrong things here is Firefox 17.0.1 getting lost when the second option is unchecked, nightly don’t have the problem anymore (supposedly 18 too)

If you don’t find the second option check, enable cleartype from the AAtuner, then disable it after (going through the config even when disabling it) this will revert the second option.

As additional explanation, to observe the effect on windows font you need a reboot; it’s not the case for Firefox, and for the fun windows keeps some place cleartyped regardless of setting in some place like the control panel so don’t get confused

Last but not least this problem was identified a long time ago, see bug 760248 but never confirmed (which can now be closed)

Hope this help
A small miss on my side, in the case of Firefox 17.0.1 with both option unchecked it's not only cleartype like a said, but grayscale almost everywhere except some UI element that are cleartyped
Here's a copy of the response I just posted to the SUMO discussion - this pretty much matches comment #84 above, I think. Summary: in FF 17.0.1, rendering is fixed for people using grayscale-only smoothing, but NOT for people with ALL font smoothing (not only ClearType) turned off; FF 18 fixes the problem for both groups of users.

>> from https://support.mozilla.org/en-US/questions/942265?page=4#answer-385326:

OK, so it looks to me like there are two issues here, and only one of them is fixed in the 17.0.1 update. Here's what I think is going on, and why some people are reporting it's "fixed", and others "still bad".

There are two separate (but related) Windows options involved here, and these lead to three distinct scenarios: (A) Smooth Edges of Screen Fonts option, found in the System / Advanced Settings / Performance Options panel. (B) ClearType (subpixel antialiasing, which gives colored fringes on the glyphs), which is enabled/disabled using the ClearType Text Tuner (accessed through the Adjust ClearType Text option in the Display control panel).

(1) If you have both Smoothing (A) and ClearType (B) enabled (which is the Windows default), there's no issue; it all works as intended. But some people dislike the result. (Note that the ClearType Text Tuner may be able to improve things, if the default settings aren't good for your graphics system.)

(2) If you have Smoothing (A) enabled but ClearType (B) disabled, you should get text that uses grayscale-only antialiasing, so there's a "smoothing" effect but without the colored fringing that ClearType can give. This configuration was broken in Azure in Firefox 17.0 - it used subpixel rendering, although it shouldn't have - and fixed in 17.0.1. So the people reporting that things are now fixed are the people who have Font Smoothing enabled, but ClearType disabled.

(3) Finally, if you have both (A) and (B) disabled, meaning you want no font smoothing AT ALL, things are still broken. These settings should give completely "un-smoothed" glyphs, with crisp edges (but jagged curves) everywhere. However, this fails badly under Azure, and you actually get poorly subpixel-rendered text. (Looking at the screenshots, it seems to be WORSE than the default where (A) and (B) are both enabled.) And 17.0.1 did not address this problem.

So I believe the people who have turned off both (A) and (B) are the ones reporting that 17.0.1 is still broken.

As far as I can tell, scenario (3) is fixed in Firefox 18 (currently in Beta), so those experiencing this issue might like to try that version (see http://www.mozilla.org/en-US/firefox/beta/) - and please provide feedback, with details of your configuration, if you DO still see problems.
Things are crystal clear now, we can just add detail like said in Comment 78, in the second case you will have grayscale or aliased mixed, depending on what font is used as default in windows (mainly SegoeUI toward Tahoma ie: hinted font for aliasing or not) and the size of the text, which is intended and normal
Well done, it seems to be exactly as said.  On the beta with azure enabled (and both font smoothing options having been off) it's working perfectly for me.
I updated four Win7 systems to 17.0.1 but still the font are antialiased which I do not like. (All CleareType and font smoothing options are disabled in windows).  After setting "gfx.content.azure.enabled" to "false" it's fine on all systems. 
But for very small fonts it looks worse that FF16 or earlier.
Blocks: 818164
It still looks pretty ugly in FF18 with ClearType disabled and the azure setting set to false.
This is how it used to look like in FF16 and looks like in FF17/18 with direct2d disabled.
This bug is closed. Please see the follow up bug 818164.
Summary: Font Issue in FF 17 → Azure does not honor Windows cleartype setting, causing font issue in FF 17
Is it possible this patch caused this issue?  https://bugzilla.mozilla.org/show_bug.cgi?id=856419
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: