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.
I see from your screenshot that ClearType is disabled in the OS settings, and based on other reports of similar issues , 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.
Err, the "" 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
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.
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.
(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).
With the new landings in bug 661471, I guess this can be marked as fixed...
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...
Yes, I can confirm as well that it is working now, thx for fixing it... ;-)