662115 - DirectWrite with an anti-aliased mode does not work with certain typefaces if ClearType is disabled in the OS settings

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[breandan]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-7.0a1.en-US.win64-x86_64.installer.exe

When Aero is disabled the GUI does not display correctly. See attached screenshot for reference. Tabs are solid grey and no text appears.

Reproducible: Always

Steps to Reproduce:
1. Turn off Aero in Windows 7 64-bit (Control Panel\System and Security\System, Advanced system settings, Performance, Settings, Adjust for best performance.)
2. Start the latest Nightly Build.

Actual Results:  
GUI renders without any text, page content also appears missing.

Comment 1

[Kai Liu]

I see from your screenshot that ClearType is disabled in the OS settings, and based on other reports of similar issues [1], I am almost certain that your problem is caused by the CT setting that you changed during your Aero/Classic switch).

I can reliably reproduce this problem of text not being rendered if using DW in GDI classic mode if ClearType is disabled.

The ability to use GDI classic with DW was exposed in bug 642589 and in bug 661471.  This problem was not noticed with 642589 because people who explicitly changed the ClearType rendering mode are not people who run with CT disabled.  This problem became noticeable with 661471 since that switched on GDI classic for people who have CT disabled in the OS.

Comment 2

[Kai Liu]

Err, the "[1]" in the previous comment was meant to refer to:
http://forums.mozillazine.org/viewtopic.php?p=10871297#p10871297
http://forums.mozillazine.org/viewtopic.php?p=10875113#p10875113

Comment 3

[Kai Liu]

It just occurred to me that the problem isn't with GDI classic per se (since that wouldn't make a whole lot of sense), but rather with forcing DW to use an anti-aliased mode when ClearType is not available (that does make sense).

These are the DW modes:
http://msdn.microsoft.com/en-us/library/dd368118.aspx

Note that the default mode 0 (to which our "-1, we-don't-care" effectively corresponds to) is "the rendering mode is determined automatically".  It just so happens that it corresponds with RENDERING_MODE_CLEARTYPE_NATURAL under normal circumstances, but when CT is disabled, it appears to correspond with RENDERING_MODE_ALIASED.

So when we change the setting away from the default, we are not letting it fall back to RENDERING_MODE_ALIASED.  This problem of disappearing text could be observed when the rendering mode is set to 2, 3, 4, or 5 (it just so happens that for people who override this setting, 2 is the one that they are interested in), so the problem is not specific to GDI classic.

Finally, I couldn't help but notice that the UI text (rendered using Segoe UI) never disappeared for me regardless of the settings that I used.  I then experimented with Consolas and Calibri, and they too never disappeared.  I suspect that if I tried the other new CT-specific typefaces that Microsoft introduced with Vista (e.g., Cambria), that they would be okay as well.  So there is something about these new typefaces that make them "immune" to this.  The cases were the UI text disappeared have all been cases where the UI typeface was switched from Segoe UI to Tahoma.

Comment 4

[Kai Liu]

Oh, I should add that Calibri, Segoe UI, et. al. continue to be rendered using CT when CT is disabled in the OS, so a tl;dr version would be, "DW is capable of forcing CT when CT is off in the OS only with CT-optimized typefaces, and not with other typefaces."

I find this a little odd, BTW, since GDI never had any problems with forcing CT when CT was off in the OS.

Comment 5

[Bas Schouten (:bas.schouten)]

(In reply to comment #4)
> Oh, I should add that Calibri, Segoe UI, et. al. continue to be rendered
> using CT when CT is disabled in the OS, so a tl;dr version would be, "DW is
> capable of forcing CT when CT is off in the OS only with CT-optimized
> typefaces, and not with other typefaces."
> 
> I find this a little odd, BTW, since GDI never had any problems with forcing
> CT when CT was off in the OS.

UI text is actually often drawn with a separate rendering path since it contains transparent layers with text. I'm not sure if this is true for non-glass though.

Comment 6

[Kai Liu]

(In reply to comment #5)
> UI text is actually often drawn with a separate rendering path since it
> contains transparent layers with text.

Tahoma in the UI falls prey to the problem (bug 661471 comment 46) and when I tried Calibri and Consolas, it was in the content, not the UI (and I just checked: Segoe UI in content is fine too).

Comment 8

[Kai Liu]

With the new landings in bug 661471, I guess this can be marked as fixed...

Comment 9

[breandan]

Yep, I can verify this as fixed. Nice job guys, the speed and efficiency of which this was addressed really floors me. The Mozilla open-sourcing collaborative at it's best...

Comment 10

[Marek Raida]

Yes, I can confirm as well that it is working now, thx for fixing it... ;-)