588880 - D2D text in Firefox chrome and content looks awful on Win 7

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Asa Dotzler [:asa]]

Attachment: screenshot showing ugly text

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.

Comment 1

[Asa Dotzler [:asa]]

Attachment: screenshot comparing content text between trunk (left) and 3.6 (right)

Comment 2

[Asa Dotzler [:asa]]

Attachment: screenshot comparing chrome text between trunk (top) and 3.6 (bottom)

Comment 3

[Asa Dotzler [:asa]]

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.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 5

[Asa Dotzler [:asa]]

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.

Comment 6

[Jonathan Kew [:jfkthame]]

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.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you work on this, Jonathan?

Comment 8

[Jonathan Kew [:jfkthame]]

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?

Comment 9

[Asa Dotzler [:asa]]

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

Comment 10

[Bas Schouten (:bas.schouten)]

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.

Comment 11

[u310142]

(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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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.

Comment 13

[Asa Dotzler [:asa]]

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.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 15

[Asa Dotzler [:asa]]

Attachment: not-zoomed screenshot of ugly text in Firefox

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 17

[Asa Dotzler [:asa]]

Attachment: asa's thinkpad x301 driver information

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

Comment 18

[u310142]

(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.

Comment 19

[u310142]

Attachment: Minefield D2D Chrome compared with FF3.6 Chrome

Comment 20

[Bas Schouten (:bas.schouten)]

(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.

Comment 21

[u310142]

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?

Comment 22

[Bas Schouten (:bas.schouten)]

(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.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 24

[Bas Schouten (:bas.schouten)]

(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.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 26

[Bas Schouten (:bas.schouten)]

(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.

Comment 27

[Asa Dotzler [:asa]]

Attachment: firefox and ie text in chrome compared

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"

Comment 28

[Asa Dotzler [:asa]]

Attachment: 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.

Comment 29

[Bas Schouten (:bas.schouten)]

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

Comment 30

[Emanuel Hoogeveen [:ehoogeveen]]

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?

Comment 31

[Csaba Kozák [:WonderCsabo]]

Bas, how will Fx handle this blurry fonts issue? 

Will Bug 574976 attachment 469999 [details] [diff] [review] resolve this?

Comment 32

[Bas Schouten (:bas.schouten)]

(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.

Comment 33

[Csaba Kozák [:WonderCsabo]]

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

Comment 34

[John Daggett (:jtd)]

(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.

Comment 35

[Asa Dotzler [:asa]]

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.

Comment 36

[Bas Schouten (:bas.schouten)]

(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.

Comment 38

[Joe Drew (not getting mail)]

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.

Comment 39

[Bas Schouten (:bas.schouten)]

(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.

Comment 40

[Asa Dotzler [:asa]]

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?

Comment 41

[Danial Horton]

IE9 does not use DirectWrite on the GUI.

Comment 42

[Scott A.]

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.

Comment 43

[Bas Schouten (:bas.schouten)]

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

Comment 44

[Bas Schouten (:bas.schouten)]

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.

Comment 45

[Asa Dotzler [:asa]]

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.

Comment 46

[[Baboo]]

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?

Comment 47

[u310142]

Yes, that is bug 612846.

Comment 48

[Steve Scott (pxbugz)]

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