Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED

Status

()

Core
Graphics
--
major
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: breandan, Unassigned)

Tracking

Trunk
All
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Fix in bug 661471, part 6], URL)

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
Keywords: 64bit
Version: unspecified → Trunk

Updated

6 years ago
Component: Toolbars → Graphics
Product: Firefox → Core
QA Contact: toolbars → thebes

Comment 1

6 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 64bit
Hardware: x86_64 → All
Summary: UI rendering error with Aero disabled → DirectWrite with "GDI classic" rendering does not work if ClearType is disabled in the OS settings

Comment 2

6 years ago
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

Updated

6 years ago
Blocks: 642589

Comment 3

6 years ago
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.
Summary: DirectWrite with "GDI classic" rendering does not work if ClearType is disabled in the OS settings → DirectWrite with an anti-aliased mode does not work with certain typefaces if ClearType is disabled in the OS settings

Comment 4

6 years ago
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.
(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

6 years ago
(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).
Duplicate of this bug: 662329

Comment 8

6 years ago
With the new landings in bug 661471, I guess this can be marked as fixed...
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Fix in bug 661471, part 6]
(Reporter)

Comment 9

6 years ago
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

6 years ago
Yes, I can confirm as well that it is working now, thx for fixing it... ;-)
You need to log in before you can comment on or make changes to this bug.