For the last few days the text in Firefox, both in chrome and in content, looks pretty awful. I checked my cleartype settings and nothing's changed there. I'll try to get a regression range today. Screenshot attached showing how bad the fonts look.

cc'ing a few people who might at least know where this bug should live. i think it's a bad enough regression that it ought to block the release.

Looks like we might be drawing the text twice or something? Or is this D2D and DirectWrite being enabled? Asa, can you try flipping D2D on or off?

roc, if I've done about:config things correctly then I see this with d2d/dwrite on and off. I think you're right about drawing the text twice. I compared even closer closeups in photoshop and it looks like the the anti-aliased bits (the part that's easiest to judge) have an opacity several times more than they do in the 3.6 case. So we might even be over drawing it three or four times.

From the screenshots, it looks like the problem is specifically with <b>bold</b> text; I wonder if we're incorrectly triggering a "fake-bold" effect in addition to choosing the actual bold face.

Can you work on this, Jonathan?

This seems to be happening only with D2D enabled, at least on my system. Asa, can you try setting mozilla.widget.render-mode to 0 (not -1), and see if that makes any difference?

Jonathan, you are correct. I had not disabled D2D correctly. With D2D disabled, the fonts look much better.

I might note non-zoomed in screenshots will be a lot easier to judge for fonts, since the sub-pixel AA will not work when a screenshot is zoomed. For chrome we have the downside with D2D we do not draw sub-pixel AA on transparent surfaces, and the chrome window was made transparent for the aero theme.

(In reply to comment #10) > For chrome we have the downside with D2D we do not draw sub-pixel AA on > transparent surfaces, and the chrome window was made transparent for the aero > theme. Is it not possible to use sub-pixel AA on transparent surfaces? Also, is the Status Bar considered a transparent surface? Because the text there also looks bad.

(In reply to comment #11) > (In reply to comment #10) > > For chrome we have the downside with D2D we do not draw sub-pixel AA on > > transparent surfaces, and the chrome window was made transparent for the aero > > theme. > > Is it not possible to use sub-pixel AA on transparent surfaces? Not with D2D. See bug 579276.

This makes our new "Firefox" button and other UI in win7 look like crap. Can we replace the "Firefox" in the Firefox button with an image or something? I don't see how we can ship something like this.

I don't see this with D2D enabled on my Lenovo laptop, btw. Again, some non-zoomed in screenshots would be helpful.

Yeah, totally not seeing that. Asa, can we get your driver infoz, too?

not sure if this is the information you need. if not, please provide instructions on how to get the right info.

(In reply to comment #16) > Yeah, totally not seeing that. Asa, can we get your driver infoz, too? Not sure how you can not see this with D2D on. Bas said that sub-pixel AA is not used in the chrome with D2D on.

(In reply to comment #18) > (In reply to comment #16) > > Yeah, totally not seeing that. Asa, can we get your driver infoz, too? > > Not sure how you can not see this with D2D on. Bas said that sub-pixel AA is > not used in the chrome with D2D on. That's different, it's true that it's not used, but in your screenshot it looks quite alright actually, just as on some other machines. I found an NVidia machine of mine where I can reproduce it though. I can also reproduce it with a simple test-case in IE9 platform preview, as such I'm bringing it to the attention of Microsoft.

That's because I used the cleartype tuner to adjust the look. With the default settings it looks worse. Good that you bring it to the attention of Microsoft. Is this on connect? If so, could you post the link?

(In reply to comment #21) > That's because I used the cleartype tuner to adjust the look. With the default > settings it looks worse. > > Good that you bring it to the attention of Microsoft. Is this on connect? If > so, could you post the link? No, I've sent the mail to a couple of people I've had contact with about D2D before and that have been helpful in the past. I'll post on this bug if I receive any useful information.

We actually could make D2D text look good when it's over an opaque background in a translucent surface. We can detect that in layout and communicate it back to cairo/D2D, then in cairo/D2D, copy the current surface contents under the text to an opaque temporary surface, draw the text onto that temporary surface, then copy back to the translucent surface.

(In reply to comment #23) > We actually could make D2D text look good when it's over an opaque background > in a translucent surface. We can detect that in layout and communicate it back > to cairo/D2D, then in cairo/D2D, copy the current surface contents under the > text to an opaque temporary surface, draw the text onto that temporary surface, > then copy back to the translucent surface. Yeah, we discussed that in the GFx meetings and although the performance impact is acceptable it can be done. It would require API adjustments though. However the problems seen here are not due to grayscale AA, I've been able to tweak settings to make it look 'fine' on grayscale AA. This is more to do with light text on dark backgrounds. I've created a test page that also renders poorly in IE9 on some hardware, and sent it with a screenshot to Microsoft.

I'm going to optimistically block on this in the hope that we can get either component alpha or a fix via a D2D update or tweak or something.

(In reply to comment #25) > I'm going to optimistically block on this in the hope that we can get either > component alpha or a fix via a D2D update or tweak or something. We've got a tweak which makes the grayscale case look much better. Not as good as subpixel, but pretty good. I'll look into it again soon.

IE9 also does not use sub-pixel aa in its tabs. This screenshot shows their greyscale aa looking a lot cleaner than ours, though. Particularly obvious in the stems of the "i" and "T"

What's really interesting is that we're truer to the fidelity of the font shapes than IE for several important characters. Look at the "a" and the "e" for example. Still, I think if that's the trade-off, we should make that trade. The IE9 text looks better even if it's less accurate.

I believe they're still using GDI for their chrome area, although I'm not 100% sure. But it would explain both the phenomena.

I've also seen comparisons of the content area made since IE9's beta release though. Perhaps a few more close-ups would be useful?

Bas, how will Fx handle this blurry fonts issue? Will Bug 574976 attachment 469999 [details] [diff] [review] resolve this?

(In reply to comment #31) > Bas, how will Fx handle this blurry fonts issue? > > Will Bug 574976 attachment 469999 [details] [diff] [review] resolve this? Not at all, it's completely unrelated. We have some ideas that we're working on for getting subpixel AA and some workarounds that make it look better with just grayscale.

Oh, sorry. Could you link the bugs, please? If exist.

(In reply to comment #28) > Created attachment 478631 [details] > firefox and ie9 grayscale aa fidelity to font question > > What's really interesting is that we're truer to the fidelity of the font > shapes than IE for several important characters. Look at the "a" and the "e" > for example. Still, I think if that's the trade-off, we should make that trade. > The IE9 text looks better even if it's less accurate. In this case what you're seeing is subpixel placement vs. integer pixel placement. Subpixel AA is usually done with subpixel placement of glyphs along a line of text, this produces rendering that is closer to the fidelity of the original design. A good example of this is Safari/Mac which does subpixel AA but *not* subpixel placement on all characters, even with 'text-rendering: optimizeLegibility;" applied. One thing to consider is whether it would be better or not to use integer pixel placement when grayscale AA is in use on Windows. There are another set of problems with that but at least it will improve legibility of UI text.

Another thing to consider here in optimizing text in the UI is that while we have a lot more of it that's dark on light standard weight, the big Firefox button is light on dark and bold. They seem to be differently affected by the current state of anti-aliasing, with the light on dark and bold being worse in appearance.

(In reply to comment #35) > Another thing to consider here in optimizing text in the UI is that while we > have a lot more of it that's dark on light standard weight, the big Firefox > button is light on dark and bold. They seem to be differently affected by the > current state of anti-aliasing, with the light on dark and bold being worse in > appearance. This is a bug in DirectWrite, I've submitted a testcase for this to MS that also reproduces the issue in IE9. They've confirmed they're working on it.

We should probably just dupe this to whatever bug we're using for "light text on dark background looks bad," and open new bugs for whatever other issues exist.

(In reply to comment #38) > We should probably just dupe this to whatever bug we're using for "light text > on dark background looks bad," and open new bugs for whatever other issues > exist. This bug is actually two-fold, the text in content is indeed the light text dark background color. We've also found that some machines produce worse results in the case of grayscale than others. (IE9 does not use directwrite in its chrome) I've sent this screenshot to MS and am awaiting a response.

in comment #34 John Daggett wrote: > One thing to consider is whether it would be better or not to use integer pixel > placement when grayscale AA is in use on Windows. There are another set of > problems with that but at least it will improve legibility of UI text. After using IE 9 pretty heavily for a couple of weeks and coming back to Firefox, I'm absolutely convinced that the IE9 grayscale AA in tab titles is much more legible (and "prettier" too.) We should absolutely make this change. Should I file a new bug for that?

IE9 does not use DirectWrite on the GUI.

Since there is only so much that can be done about it outside of Microsoft, maybe it should be turned into a meta bug and add component alpha, sub-pixel AA and some of the remaining graphics bugs as dependencies.

We've got large improvements coming for the UI at least by bypassing some MS rendering code, see the picture on bug 622482.

I believe this will be sufficiently improved by the landing of bug 622482 to mark this resolved. We do still use DWrite for the GUI, but we've now got subpixel-AA again.

sorry for the bugspam but I just have to say YAY!! Thank you so much, Bas and others, for making this happen. Find me at the next gathering and the beers are on me.

When using the add-on "Vertical Tabs" some parts of chrome like the URL-bar fall-back to rendering with greyscale anti-aliasing. Is this outside the scope of this bug report?

Yes, that is bug 612846.

Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre