635490 - Text using hardware acceleration looks inferior to and considerably different from text with acceleration disabled and on other browsers [meta]

Status: NEW

(Core :: Graphics, defect, P3)

Description

[orangezilla]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110218 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110218 Firefox/4.0b12pre

Text with hardware acceleration enabled looks fatter, blurry, and with frequent coloration visible on black text with hardware acceleration enabled on Firefox 4. Examining the text close up shows Firefox 4 with hardware acceleration enabled uses a completely different pattern of aliasing/shading.

Reproducible: Always

Steps to Reproduce:
1. Take screenshots of portions of text on a webpage in Firefox 4 with acceleration on, then disable acceleration in Options>Advanced>General.
2. Restart Firefox, take screenshots of the same text/
3. Take screenshots of the same text in other browsers.
Actual Results:  
The screenshots of text from Firefox 4 with acceleration enabled look considerably inferior to Firefox 4 with acceleration disabled, Opera 11, Chrome/Iron 9, Internet Explorer 9 Release Candidate (which also uses hardware acceleration).

Expected Results:  
Text with hardware acceleration enabled in Firefox 4 should not look completely different and inferior to text with acceleration disabled on Firefox 4 and in other browsers.

Comment 1

[orangezilla]

Attachment: Zoomed comparison of text in FF4 with/without hw accel, IE9 & Opera 11

Firefox 4 without acceleration enabled, Opera 11 and Internet Explorer 9 RC all show the same pattern of aliasing, albeit a slightly different shading, Firefox 4 with hardware acceleration on seems to follow no logical pattern.

Comment 2

[orangezilla]

Attachment: Comparison of text from mozillazine on FF4 with hwa on/off, Opera 11, IE9, SRWare Iron 9

Comparison from http://forums.mozillazine.org/viewtopic.php?f=23&t=2060933&p=10437617#p10437617

Comment 3

[orangezilla]

Should add, I am using NVidia 9800GT 1GB, 258.96 driver, Windows 7 Home Premium 32 bit.

Comment 4

[Bas Schouten (:bas.schouten)]

Personally I'd say the DWrite version looks a little better in your comparison screenshot. The kerning is more consistent(because of subpixel positioning), look for example in the 'sit' in 'position' where the gridfitting moves the center i way too far to the left, or the same for the 'o' in 'ion' or the 'lit' in 'little'. The subpixel AA also isn't as washed out (the text in the other cases is a little too thin, causing it to look more grey than black). But I can see how you might say the DWrite case is a bit 'blurred'.

Comment 5

[orangezilla]

(In reply to comment #4)
> Personally I'd say the DWrite version looks a little better in your comparison
> screenshot. The kerning is more consistent(because of subpixel positioning),
> look for example in the 'sit' in 'position' where the gridfitting moves the
> center i way too far to the left, or the same for the 'o' in 'ion' or the 'lit'
> in 'little'. The subpixel AA also isn't as washed out (the text in the other
> cases is a little too thin, causing it to look more grey than black). But I can
> see how you might say the DWrite case is a bit 'blurred'.
I really think it's stretching it very far to say it looks better, I don't think anyone on mozillazine would agree with that or elsewhere. I agree the shape of the text may look better, but that is no good if you then get excessive blurring and noticeable color fringing that makes it really **** the eyes to read for any length of time. Someone on feedback summed up to a tee how text is currently looking to me:

"The words on the screen (only while using Firefox) frequently blur, with a purple-blue hint (like trying to watch a 3D movie w/o glasses)."

http://input.mozilla.com/en-US/beta/search?product=firefox&version=4.0b11&sentiment=sad&q=3D+movie+

Comment 6

[Bas Schouten (:bas.schouten)]

(In reply to comment #5)
> I really think it's stretching it very far to say it looks better, I don't
> think anyone on mozillazine would agree with that or elsewhere. I agree the
> shape of the text may look better, but that is no good if you then get
> excessive blurring and noticeable color fringing that makes it really hard on
> the eyes to read for any length of time. Someone on feedback summed up to a tee
> how text is currently looking to me:
> 
> "The words on the screen (only while using Firefox) frequently blur, with a
> purple-blue hint (like trying to watch a 3D movie w/o glasses)."
> 
> http://input.mozilla.com/en-US/beta/search?product=firefox&version=4.0b11&sentiment=sad&q=3D+movie+

It may or may not be true that the majority feels the rendering is poorer. This is very hard to say because people that are unhappy about their experience are more likely to voice their opinion than people that are happy.

To look at input.mozilla.com in a very simple manner:

The word 'font*' occurs in 199 out of 31000 issues with Windows 7 beta 11. This often refers to font rendering issues like you describe.

Blurry occurs in 46 out of 31000 issues and mostly refers to text. But this does have overlap with the first search query.

The word 'text' occurs roughly 400 out of 31000 issues but usually does not refer to actual test rendering but to things like 'typing text in <x> results in <y>' kind of issues. Less than 20% is actually about the way text looks.

We know that 30% of our Windows 7 users are using Direct2D after the new blacklisting logic (it was 60% in beta 10). So we can assume (assuming the experiencing is roughly as good with as without D2D), that 10000 of the people having issues have D2D running. Assuming all blurry text complaints and such are D2D users this means a very rough estimate 300/10000 users on the new fonts are having issues with them. It seems funnily enough of the 10000 users that would theoretically have gone from D2D back to GDI a much smaller, but definitely present amount reports font rendering improvements.

I've been quite generous here and still only getting to a 3% unhappiness. I don't think that's super-high for a fundamental font rendering change.

You have to remember when microsoft first introduced cleartype as on by default there was a lot of negative response from people. Now most people are annoyed when they don't get cleartype.

There's definitely some issues with fonts which should be resolved, but there's also just a bunch of getting used to something. This is somewhat of an uphill struggle since most applications use traditional rendering though.

Comment 7

[Jonathan Kew [:jfkthame]]

Note that IE9 *does* use subpixel positioning, and thus renders FF4-like text, but only when it is running in "native" IE9 rendering mode. If it decides to run in an earlier compatibility mode, it will use GDI-like rendering.

In the case of the mozillazine forum page mentioned above, the page includes
  <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
which disables subpixel positioning in IE9.

Comment 8

[orangezilla]

(In reply to comment #7)
> Note that IE9 *does* use subpixel positioning, and thus renders FF4-like text,
> but only when it is running in "native" IE9 rendering mode. If it decides to
> run in an earlier compatibility mode, it will use GDI-like rendering.
> 
> In the case of the mozillazine forum page mentioned above, the page includes
>   <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
> which disables subpixel positioning in IE9.
Indeed, confirmed from posts on mozillazine, is hardware acceleration even running at all with IE7 standards mode? I have done new attachments to show the difference between IE9 text with h/w acceleration on/off vs FF4 with it on/off

(In reply to comment #6)
> I've been quite generous here and still only getting to a 3% unhappiness. I
> don't think that's super-high for a fundamental font rendering change.
> 
> You have to remember when microsoft first introduced cleartype as on by default
> there was a lot of negative response from people. Now most people are annoyed
> when they don't get cleartype.
Just because people aren't complaining doesn't mean they like it. It may take a while for people to realise that (i) FF4 has a new feature called hardware acceleration and (ii) that it affects the way text looks. Given the revelation from Jonathan above that MS was disabling acceleration totally or partly for mozillazine, that brings into question why they are doing that- because they know text looks bad on certain pages, forums that run on a certain software, maybe? If so would Mozilla consider doing something similar? Though, even if I force IE9 hardware acceleration on that page, I still think the IE9 hardware accelerated text has the edge over FF4, the letters look a little clearer & sharper on IE9 with h/w accel on than FF4, particularly the cs, ws, bs, the capital DW, even the dash between sub-pixel. The zoomed screenshot seems to suggest IE9 creates more white space between letters, between the i and the x, the x and the e, the e and the l which presumably makes the text clearer.

Comment 9

[orangezilla]

Attachment: Comparison of text betw FF4 with hwa on/off, Opera 11, IE9 hwa on/off, SRWare Iron 9

Comment 10

[orangezilla]

Attachment: Zoomed comparison of text in FF4 & IE9 with/without hw accel

Comment 11

[orangezilla]

Attachment: Zoomed comparison of double lls in FF4 with/without hw/accel, IE9 with

OK, putting letter/letters into feedback brings a few more observations, particularly that letters seem to close, i.e. double lls tend to seem joined

http://input.mozilla.com/en-US/beta/search?product=firefox&version=--&q=Letters+close+

Taking the latest xbuk comparison, if you look at the attached zoomed view of the double lls, you can see that IE9 RC (with acceleration on) uses the same light colour to the left of the l's as well as the uprights of the u's, as Firefox with acceleration disable also does, albeit a different color. In the Firefox 4 accelerated screenshot, the colours inbetween the o and u and the two lls are two similar, which when viewed at normal size gives the appearance of being joined. 

To me the double lls still look better, and the text in general does in Firefox 4 here with acceleration off. I note the aliasing of the double lls is symmetrical with acceleration off, and even at normal size (see second attchment below) I can see that the ls are not the same in the two hardware accelerated cases.

Comment 12

[orangezilla]

Attachment: Comparison of text on xbuk.co.uk FF4 hw accel off/on, IE9 hw accel on

Comment 13

[enfantsauvage]

Attachment: Comparison of text with HW on & off where a really noticable diference in quality can ealily be seen.

The first two samples are from a site that uses the PT Sans Narrow font (embedded via Google Fonts).
The third and the last sample are from Gmail.

I have noticed that the rendering quality varies between different sites and fonts. 
On some sites and with some fonts, as you can see, the issues are so severe that they are almost unusable/unreadable. 
This is not a matter of opinion, or of getting used to (as one poster suggested).
These are facts, and therefore this is a bug.

Comment 14

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

I think the cases where we render differently from IE9 (in IE9 mode) should at least be investigated so we understand what's happening there.

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to comment #13)
> The third and the last sample are from Gmail.

This is bug 589124. It's caused by an error in the site's CSS; they're asking for bolder-than-bold, and so they get it. The only reason it worked "better" under GDI is because GDI didn't support font families with more than two weights, so we were unable to fully honor what the CSS style requests.

From the screenshot in bug 589124, it looks like IE9 may have decided to include a "hack" such as forcing the vertical metrics of Arial Black to match those of Arial, even though that's not what the font itself says. (An earlier Platform Preview did not do this, and showed the same button-sizing issue as FF.) We could consider doing this if we want to mitigate the effects of poorly-designed CSS.

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to comment #13)
> The first two samples are from a site that uses the PT Sans Narrow font
> (embedded via Google Fonts).

Could you provide the URL for this example, please?

Comment 17

[Jonathan Kew [:jfkthame]]

Attachment: comparison of PT Sans Narrow in FF4b12pre and IE9Preview

Comparing the rendering of PT Sans Narrow on the Google Fonts site, I'd say FF4 and IE9 Preview look extremely similar. I suspect that something in the CSS on the site mentioned in comment 13 is causing us to hit the _cairo_dwrite_manual_show_glyphs_on_d2d_surface rendering path in the cairo-d2d backend (perhaps that background is a semi-opaque color?). I would agree that the resulting antialiasing looks awful. It's similar to what we get in the URL bar, etc, with excessively strong color fringing.

Comment 18

[Bas Schouten (:bas.schouten)]

(In reply to comment #8)
> (In reply to comment #7)
> > Note that IE9 *does* use subpixel positioning, and thus renders FF4-like text,
> > but only when it is running in "native" IE9 rendering mode. If it decides to
> > run in an earlier compatibility mode, it will use GDI-like rendering.
> > 
> > In the case of the mozillazine forum page mentioned above, the page includes
> >   <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
> > which disables subpixel positioning in IE9.
> Indeed, confirmed from posts on mozillazine, is hardware acceleration even
> running at all with IE7 standards mode? I have done new attachments to show the
> difference between IE9 text with h/w acceleration on/off vs FF4 with it on/off

I'm guessing it is, we can trivially disable subpixel positioning with DirectWrite and keep hardware acceleration on. It's not hard, but I wouldn't want to for no reason because the ability to subpixel position glyphs is -good-. I'm guessing in IE7 compatibility mode they're just rendering specifying GDI rendering/measuring, this is just a flag one can pass to DirectWrite to get the old style rendering. Even when hardware acceleration is on.

> 
> (In reply to comment #6)
> > I've been quite generous here and still only getting to a 3% unhappiness. I
> > don't think that's super-high for a fundamental font rendering change.
> > 
> > You have to remember when microsoft first introduced cleartype as on by default
> > there was a lot of negative response from people. Now most people are annoyed
> > when they don't get cleartype.
> Just because people aren't complaining doesn't mean they like it. It may take a
> while for people to realise that (i) FF4 has a new feature called hardware
> acceleration and 

That's just the thing. If people are annoyed by something they generally report it under 'issues' amd they don't care what causes it and don't need to know there's a feature called hardware acceleration to say text looks bad. I'm not saying people -like- it because they aren't complaining, nobody liked cleartype when it was first released. I'm not opposed to the idea very few people really 'like' it. I'm saying people generally don't seem to be strongly disliking it. The fact you feel strongly about this, and a number of other vocal people do, does not make it so.

It's not impossible for a large group of people to dislike it, and maybe it's true. But there's no statistical evidence that this large group of people exists in a statistically random sample.

If you have evidence this large group of people disliking it exists I'd love to see it. We might consider passing flags to DirectWrite to render GDI style if this was the case. Obviously a select group discussing the subject on mozillazine that is by no means a random sample is not evident of this. Those that are most vocal are not per sé more important.

> (ii) that it affects the way text looks. Given the revelation
> from Jonathan above that MS was disabling acceleration totally or partly for
> mozillazine, that brings into question why they are doing that- because they
> know text looks bad on certain pages, forums that run on a certain software,
> maybe?

IE7 compatibility is requested by mozillazine. There's numerous reasons this could be. It's possible to do something similar for firefox I'd say, but it's one of those things that I'd say is fairly dodgy if you want a standards compliant web. Webpages should be designed so that they don't rely on certain font metrics or things like that, and obscure 'compatibility' modes should be avoided where possible in my opinion.

Comment 19

[enfantsauvage]

Attachment: PT Sans Narrow in Firefox 4 beta 11 (HW on & off) and IE 9 RC1

This is how the font looks from my PC. 
I'm using a Windows 7 Ultimate x64 OS. 
Graphic card is ATI HD 5750 (Catalyst Version 10.11).

I must admit that the difference is not so severe on these samples, but still Firefox 4 (HW on) is noticeable bolder than IE9 and Firefox 4 (HW off).

Comment 20

[enfantsauvage]

(In reply to comment #16)
> (In reply to comment #13)
> > The first two samples are from a site that uses the PT Sans Narrow font
> > (embedded via Google Fonts).
> 
> Could you provide the URL for this example, please?

The url is www.reikimacedonia.com

Comment 21

[orangezilla]

(In reply to comment #18)
> I'm guessing it is, we can trivially disable subpixel positioning with
> DirectWrite and keep hardware acceleration on. It's not hard, but I wouldn't
> want to for no reason because the ability to subpixel position glyphs is
> -good-. I'm guessing in IE7 compatibility mode they're just rendering
> specifying GDI rendering/measuring, this is just a flag one can pass to
> DirectWrite to get the old style rendering. Even when hardware acceleration is
> on.
OK, thanks for the explanation.


> It's not impossible for a large group of people to dislike it, and maybe it's
> true. But there's no statistical evidence that this large group of people
> exists in a statistically random sample.
> 
> If you have evidence this large group of people disliking it exists I'd love to
> see it.
I think people are more likely to send feedback about something that is >obviously< broken. Unless people do comparisons like me, or have seen such comparisons posted they may not twig the text looks inferior, especially if they have never seen any discussion of it, or they even know that text is now rendered by GPU by default.


> IE7 compatibility is requested by mozillazine. There's numerous reasons this
> could be. It's possible to do something similar for firefox I'd say, but it's
> one of those things that I'd say is fairly dodgy if you want a standards
> compliant web. Webpages should be designed so that they don't rely on certain
> font metrics or things like that, and obscure 'compatibility' modes should be
> avoided where possible in my opinion.
OK, fair enough.

Could you address my points and attachments in comment 11 and comment 12? Internet Explorer 9 definitely seems to better separating letters by making sure white space or a lighter colour occurs between them, where Firefox 4 often has darker adjacent colours giving the joined double l look. Can you also address the symmetry issue, why it is an improvement that I can see two identical letters are different widths at normal size? Are you in contact with Miccrosoft at all on the development of DirectWrite feature, do you have any influence in improvements that are made to it?

Comment 22

[Bas Schouten (:bas.schouten)]

(In reply to comment #21)
> Could you address my points and attachments in comment 11 and comment 12?
> Internet Explorer 9 definitely seems to better separating letters by making
> sure white space or a lighter colour occurs between them, where Firefox 4 often
> has darker adjacent colours giving the joined double l look. Can you also
> address the symmetry issue, why it is an improvement that I can see two
> identical letters are different widths at normal size? Are you in contact with
> Miccrosoft at all on the development of DirectWrite feature, do you have any
> influence in improvements that are made to it?

Jonathan is a better person to answer those questions. His knowledge is far superior to my own.

Part of the issue is we have our own rendering path for drawing subpixel AA to transparent surfaces when text is over opaque pixels. This is something DirectWrite doesn't allow, however our rendering path isn't quite as good quality wise as DirectWrite's for numerous reasons.

We are in direct contact with the DirectWrite team at Microsoft and I like to think we have some level of influence as one of their biggest users :).

Comment 23

[Jonathan Kew [:jfkthame]]

(In reply to comment #22)
> Jonathan is a better person to answer those questions. His knowledge is far
> superior to my own.

I don't think that's at all true once it gets to the details of GPU rendering, color processing, etc!

But anyway, a couple of comments. Regarding "double l's" and similar observations: with h/w accel off, it's expected that every instance of "l" in a string of text will look the same, with identical antialiasing (whether good or bad!). This is because the position of each glyph is forced to align to the pixels of the display, so the outline gets rasterized and antialiased in the same way every time. (Well, I expect a cached bitmap is used internally.) With h/w accel enabled, however, subpixel positioning is supported, which means that glyph positions are NOT snapped to the boundaries of display pixels. And therefore successive examples of the same glyph may be rendered differently, depending on the relative alignment of the glyph outline to the pixel grid. Individually, some glyphs may be similar to their pixel-aligned versions; some may be "better", at least in the sense that the perceived shapes are more true to the original font design; and some may turn out worse. But overall, the key difference is that the glyph shapes and spacing will be more consistent. The price we pay for this is that they may appear less "sharp" because the outlines are not being forced to fit the pixel grid, and therefore there are fewer precise, strongly-defined edges.

An aside, perhaps not directly related but a significant difference between IE9 and FF4: as far as I can tell, IE9 does not seem to be applying any kerning in Latin-script text, whereas FF4 does. As an example, try <p style="font-family:arial; font-size:100px;">AVAVAVAV</p>, and note how Firefox applies the kerning (defined in the Arial font) between the "AV" and "VA" glyph pairs. I noticed this in the screenshots from xbuk.co.uk, where we can see Firefox applying kerning to the text.

We have a known problem involving antialiasing and transparency, as noted above (Bas definitely knows more about that than I do!) - the classic example of this is the URL bar, which shows bad color fringing ("rainbow" effects) if you enter something like "llllllllllllllllllllllllllllllll".

I'm not able to reproduce some of the examples cited here: I looked at www.reikimacedonia.com (see comment #13), and the rendering I get with IE9RC and FF4beta is virtually identical. I'll attach a screenshot of the two. They're not pixel-for-pixel identical, but I'd say that the overall quality is equivalent. This makes me wonder if the results are affected by other factors such as the graphics card, but I don't have access to a range of hardware to investigate this.

Comment 24

[Jonathan Kew [:jfkthame]]

Attachment: comparison of www.reikimacedonia.com, IE9RC (left) vs FF4beta12pre (right)

Comment 25

[enfantsauvage]

(In reply to comment #24)
> Created attachment 513870 [details]
> comparison of www.reikimacedonia.com, IE9RC (left) vs FF4beta12pre (right)

Hmmm... Your results seem much better than mine. For me, IE9 RC also renders very badly on www.reikimacedonia.com (almost the identical blurriness that I get with your browser).

Also, the Gmail problem for me goes beyond the bigger Archive button. The whole text has a blurriness similar to the one described for reikimacedonia. 

Will attach a capture in a minute.

Comment 26

[Jonathan Kew [:jfkthame]]

(In reply to comment #25)
> Hmmm... Your results seem much better than mine. For me, IE9 RC also renders
> very badly on www.reikimacedonia.com (almost the identical blurriness that I
> get with your browser).

Odd. Bas, any thoughts? Is this GPU- or driver-related?

I _can_ get really bad-looking antialiasing there if I go to the ClearType Tuning control panel and choose different settings, btw. With some bad choices there I can make both IE9RC and FF4b look bad. But what I haven't seen is a dramatic difference between the two when using the same settings, except in the case where FF hits the manual-subpixel path mentioned above - or of course when IE9 falls back to older compatibility modes and emulates GDI rendering.

Comment 27

[enfantsauvage]

Attachment: Comparison of Gmail in Firefox 4 beta 11 with HW on & off

I hope the blurriness is noticeable enough in these samples, but what really bothers me is that when I have Gmail open in full screen there is this turquoise like wave over the messages (nearly like they are melting :))

As I said before, I'm on a Win7 Ultimate OS x64 with a ATI 5750 graphic card (catalyst version is 10.11)

Comment 28

[Jonathan Kew [:jfkthame]]

(In reply to comment #27)
> Created attachment 513874 [details]
> Comparison of Gmail in Firefox 4 beta 11 with HW on & off

And how does Gmail in IE9 compare to Gmail in FF4b for you?

Comment 29

[enfantsauvage]

Attachment: Comparison of Gmail in Firefox 4 beta 11 (with HW on & off) and IE9RC1

(In reply to comment #28)
> (In reply to comment #27)
> > Created attachment 513874 [details]
> > Comparison of Gmail in Firefox 4 beta 11 with HW on & off
> 
> And how does Gmail in IE9 compare to Gmail in FF4b for you?

It is much better. 
I have updated the attached image to include IE9.

Comment 30

[taranli]

Attachment: Firefox 4b11 HWON/HWOFF bright colors on black comparison

The bright red/green/blue fonts look much more heavily aliased than white.  This may simply be another example of the strange sub-pixel antialiasing, but I feel it is much more severe than the rainbowing that most people are complaining about.

Comment 31

[orangezilla]

Attachment: Comparison of www.reikimacedonia.com FF4 hw accel on/off & IE9, 2 cleartype settings

Thanks Bas & Jonathan for your replies. I won't claim I understand all the technical stuff as I definitely do not - had to look up glyph, then twigged hieroglyph :)! I have realised that part of the issue is simply the cleartype settings, I looked at Jonathan's comparison of the macedonian site and was able to get quite close by adjusting my cleartype settings, although not exact (see screenshot attached, top left-right: FF4 hw off, FF4 hw on, IE9 hw on, bottom left-right, same with adjusted cleartype). Jonathan, could you possibly fill me in on your cleartype settings so I can get a better match? I think part of the problem is that the same cleartype setting gives quite significantly thinner text with hardware acceleration off, so people who like thinner text get a shock when enabling hardware acceleration, which will, of course happen automatically with the auto upgrade from 3.6 when FF4 is released- maybe there could be some kind of note on the upgrade welcome screen about this with a guide how to set cleartype?

Comment 32

[orangezilla]

Attachment: Comparison of text on xbuk.co.uk FF4 hw accel on & IE9 hw accel on, 2 cleartype settings

This screenshot again shows that IE9 seems to make a point of making sure there is light colour or no colour at all between letters, using two different cleartype settings, which makes the text seem clearer/less blurry 

(FF4 old cleartype settings, top left, new settings below, same with IE9, right)

Comment 33

[skylerlaughs]

Attachment: Text rendering difference found at www.xkcd.com

The top image is with hardware acceleration disabled. The bottom image is with hardware acceleration enabled. I am running the 02/25 nightly on Windows 7.

Is the text difference expected? Also, why is it being partially cut off?

I'm avoiding opening a new bug until I hear back for you guys.
I hope this is the right place to report this. Thanks.

Comment 34

[skylerlaughs]

I have also noticed that text is not quite as dark with layers.prefer-d3d9 enabled. This especially true for gray colored text. The lighter text is a little closer to GDI rendering and is preferable to me. Text rendering with hardware acceleration disabled is better still. I understand that opinions on this may vary, but I am unsure why layers.prefer-d3d9 should change text rendering.

Thanks again.

Comment 35

[Gian-Carlo Pascutto [:gcp]]

This bug is tagged "x86 Windows 7" and most comments here refer to that but the exact same effect exists on Vista (which also has DirectWrite support). 

FF4 with hardware acceleration has fuzzy fonts and color fringing in its UI. This is extremely obvious on my display and looks like a bad bug. So I'm surprised it's being argued here this is by design. 

IE9 with hardware acceleration also suffers from fuzzy fonts (just Google to see loads of people complaing about it) but it seems to avoid the color fringing issues in its UI. This might be due toe extensive tweaking and hacks.

There appears to be an addon that allows one to use ClearType rendering even with DirectWrite, but so far I didn't find a setup yet that combines HW accel with good looking fonts:

https://addons.mozilla.org/en-us/firefox/addon/anti-aliasing-tuner/

Comment 36

[Jonathan Kew [:jfkthame]]

(In reply to comment #33)
> Created attachment 515203 [details]
> Text rendering difference found at www.xkcd.com
> 
> The top image is with hardware acceleration disabled. The bottom image is with
> hardware acceleration enabled. I am running the 02/25 nightly on Windows 7.
> 
> Is the text difference expected? Also, why is it being partially cut off?
> 
> I'm avoiding opening a new bug until I hear back for you guys.
> I hope this is the right place to report this. Thanks.

This is a separate issue; see bug 626946.

Comment 37

[Gian-Carlo Pascutto [:gcp]]

>It's not impossible for a large group of people to dislike it, and maybe it's
>true. But there's no statistical evidence that this large group of people
>exists in a statistically random sample.
>
>If you have evidence this large group of people disliking it exists I'd love to
>see it.

If you Google this you find lots of complaints. You also find them in every Slashdot release thread.

Here's a suggestion: there is a User Studies subsystem in the beta. You could make a poll there that shows people various popular fonts in common sizes with both rendering paths (if that is technically possible) and allow them to vote what looks better. If this gathers hardware specs, you could find some relations too, for example that screen size or DPI settings influence strongly what people find better. You can then make the default behavior smarter.

>We might consider passing flags to DirectWrite to render GDI style if
>this was the case.

Unfortunately, if the "anti-aliasing-tuner" plugin I linked earlier is a reference, it seems DirectWrite+GDI style is still significantly worse than the old rendering path, and certainly doesn't look the same. Maybe even worse than DirectWrite defaults.

Comment 38

[phi2x]

Given the current initiative here http://canweshipyet.com/ to push to release, I think this bug should be requalified as hard blocker.

I can't imagine Firefox 4 being released with an inferior hardware text renderer than IE9.

Comment 39

[Gian-Carlo Pascutto [:gcp]]

This appears to be the same as what people are bitching about in:
https://bugzilla.mozilla.org/show_bug.cgi?id=594325

That bug was closed, incorrectly so it looks.

Comment 40

[orangezilla]

(In reply to comment #39)
> This appears to be the same as what people are bitching about in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=594325
> 
> That bug was closed, incorrectly so it looks.
Interesting, I note Robert asks here
https://bugzilla.mozilla.org/show_bug.cgi?id=594325#c102

for an example where there is a difference betwen rendering in FF4 and IE9 with hardware acceleration enabled, I posted such a difference in comment 32, where IE9 uses better spacing (using light, or no shading at all) between letters.

Comment 41

[mpw700]

I love Firefox and the work that goes in on it. Well done folks, but the way that text appears when the HWA is on is a deal breaker for me. In no way does the default font look superior to the way it looks with HWA off. I couldn't spend any amount of time looking at it, and I'm puzzled why there seems to be debate as to whether there's a problem. It simply looks bad when you compare it to the current version of Firefox.

Comment 42

[Bas Schouten (:bas.schouten)]

(In reply to comment #38)
> Given the current initiative here http://canweshipyet.com/ to push to release,
> I think this bug should be requalified as hard blocker.
> 
> I can't imagine Firefox 4 being released with an inferior hardware text
> renderer than IE9.

Please post screenshots of this rendering difference with IE9, on a HW accelerared IE9 page (i.e. not a page running in IE-non-9 compatibility mode). The screenshots currently here look -extremely- similar to me (for example https://bugzilla.mozilla.org/attachment.cgi?id=514259).

The answer is pretty simple, any quality IE9 has on a non-9 compatible mode page is a quality we can achieve.

Any other quality improvement can only come from either sub-pixel aligning glyphs like was done in GDI, personally I think that was very ugly, but it's not hard if we want to do it.

Of course the other option is to disable hardware acceleration, but people have that option and I certainly wouldn't want to make it the default. When we switched off older drivers and moves 30% of our Windows 7 users away from hardware acceleration, we had a -lot- more complaints about firefox being slower than we had praise about the text looking better.

Comment 43

[Bas Schouten (:bas.schouten)]

(In reply to comment #13)
> Created attachment 513817 [details]
> Comparison of text with HW on & off where a really noticable diference in
> quality can ealily be seen.
> 
> The first two samples are from a site that uses the PT Sans Narrow font
> (embedded via Google Fonts).
> The third and the last sample are from Gmail.
> 
> I have noticed that the rendering quality varies between different sites and
> fonts. 
> On some sites and with some fonts, as you can see, the issues are so severe
> that they are almost unusable/unreadable. 
> This is not a matter of opinion, or of getting used to (as one poster
> suggested).
> These are facts, and therefore this is a bug.

To be honest, I don't deny that there's certainly cases where rendering quality is worse, but I really don't see it in this screenshot. It's different, for sure. But I wouldn't say worse (or better).

Comment 44

[enfantsauvage]

(In reply to comment #42)
> (In reply to comment #38)
> > Given the current initiative here http://canweshipyet.com/ to push to release,
> > I think this bug should be requalified as hard blocker.
> > 
> > I can't imagine Firefox 4 being released with an inferior hardware text
> > renderer than IE9.
> 
> Please post screenshots of this rendering difference with IE9, on a HW
> accelerared IE9 page (i.e. not a page running in IE-non-9 compatibility mode).
> The screenshots currently here look -extremely- similar to me (for example
> https://bugzilla.mozilla.org/attachment.cgi?id=514259).
> 
> The answer is pretty simple, any quality IE9 has on a non-9 compatible mode
> page is a quality we can achieve.
> 
> Any other quality improvement can only come from either sub-pixel aligning
> glyphs like was done in GDI, personally I think that was very ugly, but it's
> not hard if we want to do it.
> 
> Of course the other option is to disable hardware acceleration, but people have
> that option and I certainly wouldn't want to make it the default. When we
> switched off older drivers and moves 30% of our Windows 7 users away from
> hardware acceleration, we had a -lot- more complaints about firefox being
> slower than we had praise about the text looking better.

Bas, have you seen the <a href="https://bug635490.bugzilla.mozilla.org/attachment.cgi?id=513876">Comparison of Gmail in Firefox 4 beta 11 (with HW on & off) and IE9RC1</a> attachment?

There is definitely a difference between the samples and I am finding Gmail much more readable with IE9RC1 than Firefox 4 (HW On).

Comment 45

[Jonathan Kew [:jfkthame]]

Attachment: enlarged comparison of IE9 text (top 3 lines) and FF4 (bottom 3 lines)

I'm attaching an enlarged extract of text from attachment 513876 [details], showing the difference between IE9 rendering (top) and FF4 with HW accel (bottom). Both are using subpixel AA and glyph positioning, but the coloring of the AA pixels on the FF4-rendered text is distinctly stronger/darker; this is why the IE9 text looks clearer (IMO) and the color-fringing effects are much less noticeable at normal size.

Comment 46

[Bas Schouten (:bas.schouten)]

(In reply to comment #45)
> Created attachment 515381 [details]
> enlarged comparison of IE9 text (top 3 lines) and FF4 (bottom 3 lines)
> 
> I'm attaching an enlarged extract of text from attachment 513876 [details], showing the
> difference between IE9 rendering (top) and FF4 with HW accel (bottom). Both are
> using subpixel AA and glyph positioning, but the coloring of the AA pixels on
> the FF4-rendered text is distinctly stronger/darker; this is why the IE9 text
> looks clearer (IMO) and the color-fringing effects are much less noticeable at
> normal size.

Hrm, I'd say the black text is better in Firefox(in IE9 it looks grey). But the grey text is definitely more pleasant in IE9. The color fringing is definitely worse in FF. In any case considering there's a difference in rendering here I guess this may be using our 'manual' sub-pixel AA rendering path for some reason. But I don't see why it would be doing that.

Comment 47

[Bas Schouten (:bas.schouten)]

Interestingly, particularly for the black text I'd say the FF HW on rendering is actually more like the GDI rendering than the IE9 RC1 rendering.

Comment 48

[skylerlaughs]

Is there anyway to get a test build of this for comparison?

>Any other quality improvement can only come from either sub-pixel aligning
>glyphs like was done in GDI, personally I think that was very ugly, but it's
>not hard if we want to do it.


Also, what going on with here?

>I have also noticed that text is not quite as dark with layers.prefer-d3d9
>enabled. This especially true for gray colored text.

Comment 49

[Alex]

(In reply to comment #46)
> In any case considering there's a difference in rendering here I
> guess this may be using our 'manual' sub-pixel AA rendering path for some
> reason. But I don't see why it would be doing that.

I can see this with the new Twitter design, the text in the header bar changes between the normal path and the manual path based on the position of the page contents underneath it.

Comment 50

[Gian-Carlo Pascutto [:gcp]]

Attachment: UI text rendering between FF4 nohw, FF4 hw and IE9RC hw

>The answer is pretty simple, any quality IE9 has on a non-9 compatible mode
>page is a quality we can achieve.

It's not only on webpages. The effects are in the UI too. In the attached comparison, you can see that FF4+HW is the only one to exhibit the color fringing in its own URL bar.

Comment 51

[Bas Schouten (:bas.schouten)]

(In reply to comment #50)
> Created attachment 515435 [details]
> UI text rendering between FF4 nohw, FF4 hw and IE9RC hw
> 
> >The answer is pretty simple, any quality IE9 has on a non-9 compatible mode
> >page is a quality we can achieve.
> 
> It's not only on webpages. The effects are in the UI too. In the attached
> comparison, you can see that FF4+HW is the only one to exhibit the color
> fringing in its own URL bar.

Well, the UI is somewhat different because IE9 doesn't accelerate that. Also note that you won't see color fringing at your top arrow, since it's pointing at grayscale anti-aliased text. (I'm not sure why it's grayscale AA though)

Comment 52

[Gian-Carlo Pascutto [:gcp]]

Attachment: UI rendering IE9RC, FF4HW, FF4NOHW

>Also note that you won't see color fringing at your top arrow, since it's 
>pointing at grayscale anti-aliased text. (I'm not sure why it's grayscale AA 
>though)

You're right; I pointed that out at first to show the blurryness is also visible in the UI in FF, but I guess that is expected.

As for the IE9 UI not being accelerated: you are probably right about the URL, but look at the tabs (see attachment): the text is more blurred than the one in FF without acceleration, although it looks like the same font and size.  
And it's *still* different from FF+HW. 

Could it be that the tabs in IE9 are using DirectWrite but with tweaks? If you look at the Google's, the 3 renderings (FFnohw, FFhw, IE9) are all different. I thought it was the background at first, but it's not the same gray.

Comment 53

[orangezilla]

Attachment: Comparison between text on Mozilla feedback top-bottom IE9 hwon, FF4 hwon, FF4 hwoff

Have a look at this comparison of text on Mozilla Feedback, I think it is hard to argue that the hardware accelerated text is easier to read here? The hardware accelerated text looks 'fuzzy' with a sort of halo around it, whereas the GDI text is sharp and easier to clear.

Comment 54

[orangezilla]

*clearer/easier to read from a distance

Comment 55

[orangezilla]

Attachment: Zoomed comparison of text on Mozilla feedback, l-r, FF4 hwon, hwoff, IE9 hwon

It is interesting to look at this zoomed, the word 'links' definitely looks better in IE9 than FF4 with acceleration on, examined close up you can see the aliasing of this word is very similiar between IE9 and FF4 with acceleration off. 

Yet for the word 'mozilla', IE9 and FF4 with acceleration on are similar to each other, but mozilla on FF4 with acceleration off is much clearer as for the uprights of the m, i and lls the GDI aliasing uses one dark upright contrasted with a light upright, whereas with directwrite, apart from the center upright of m, there is not enough contrast between the colours of the uprights.

Comment 56

[enfantsauvage]

(In reply to comment #43)
> (In reply to comment #13)
> > Created attachment 513817 [details]
> > Comparison of text with HW on & off where a really noticable diference in
> > quality can ealily be seen.
> > 
> > The first two samples are from a site that uses the PT Sans Narrow font
> > (embedded via Google Fonts).
> > The third and the last sample are from Gmail.
> > 
> > I have noticed that the rendering quality varies between different sites and
> > fonts. 
> > On some sites and with some fonts, as you can see, the issues are so severe
> > that they are almost unusable/unreadable. 
> > This is not a matter of opinion, or of getting used to (as one poster
> > suggested).
> > These are facts, and therefore this is a bug.
> 
> To be honest, I don't deny that there's certainly cases where rendering quality
> is worse, but I really don't see it in this screenshot. It's different, for
> sure. But I wouldn't say worse (or better).

Well that is exactly the problem you see. The difference is to great between the font rendering on different browsers, and as I can see from this discussion, even on same browsers but on different systems/settings. 

The fonts should look as close as it is possible to what the font designer intended them to look like. If I am using PT Sans Narrow I want it to look like PT Sans Narrow, not bolder, not different, not like Arial, not like anything else - but PT Sans Narrow.
Some fonts can cost more than a couple of hundred dollars for web embedding. Such dramatic differences between browser rendering is definitely a problem.

Comment 57

[Please Ignore This Troll (Account Disabled)]

the bug is still unconfirmed, lol?

Comment 58

[mvtodevnull]

Attachment: Comparison of IE and Firefox 4 font-rendering

A side-by-side comparison of IE and Firefox 4 font-rendering (with HW accel on). The font-rendering in Firefox 4 is considerably blurry and the line-spacing also seems a bit off.

Comment 59

[Puding]

Lol unconfirmed yet? This is really annoying. The Microsoft change that on Internet Explorer 8. Only firefox 4 has blurred letters.

To remove this annoying thing, just unmark the "Hardware acelerattor" on Options.

Comment 60

[phi2x]

(In reply to comment #59)
> Lol unconfirmed yet? This is really annoying. The Microsoft change that on
> Internet Explorer 8. Only firefox 4 has blurred letters.
> 
> To remove this annoying thing, just unmark the "Hardware acelerattor" on
> Options.

Yes. That's what I'm doing ;) But how many people will know that they can do that? Not much I think. People will simply "vote with their feet" and choose other browsers.
And Mozilla will keep wondering about why the Firefox audience is eroding...

Comment 61

[*I need to change my userid so it's less racist)]

(In reply to comment #59)
> To remove this annoying thing, just unmark the "Hardware acelerattor" on
> Options.

That's not a proper way out. I don't want to sacrifice hardware acceleration for the sake of normal fonts, I want both. Without hw acceleration Firefox is soooo slow.

Comment 62

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

(In reply to comment #58)
> Created attachment 518672 [details]
> Comparison of IE and Firefox 4 font-rendering
> 
> A side-by-side comparison of IE and Firefox 4 font-rendering (with HW accel
> on). The font-rendering in Firefox 4 is considerably blurry and the
> line-spacing also seems a bit off.

Looks like Reddit, and as far as I can tell Reddit doesn't end up with text in the "manual drawing path", so it really should look exactly like IE9. But it doesn't.

Jonathan, can you look into that? I was looking at this page:
http://www.reddit.com/r/programming/comments/f0fb0/google_removing_h264_support_in_chrome/c1ccnwg

Comment 63

[Alex]

In the Reddit screenshot IE is using GDI, which is why it doesn't match Firefox.

Comment 64

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

I don't know about the screenshot, but for me IE9 displays the Reddit page in "IE9 standards mode", which I assume means it's using DirectWrite, and the results look different to what we draw in Firefox.

Comment 65

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

Although some of that could be to do with subpixel positioning differences I guess.

Comment 66

[Jonathan Kew [:jfkthame]]

Attachment: screenshot of IE9 and FF4 rendering on reddit

On my laptop, both IE9 and FF4 are using HW-accelerated dwrite text on reddit.com, and the results look virtually indistinguishable - there are subpixel-level differences in individual glyphs, so that sometimes one looks "sharper", sometimes the other, depending where they happen to fall on the pixel grid, but there's no clear or consistent difference. The screenshot shows a fragment of the same page rendered in both; the vertical spacing differs, but as far as I can see, the quality of the glyph rendering is equivalent.

It's certainly true that the reddit screenshot from comment #58 (attachment 518672 [details]) shows "crisper" text in IE, but as already noted, it's using GDI rendering, which pixel-aligns the glyphs giving more consistent vertical strokes and edges, at the expense of more distortion from the original glyph shapes and spacing. (E.g. the lowercase "m" in comments there is horizontally compressed, and the spacing of "Min" in "Minecraft" is rather tight.)

Comment 67

[Jonathan Kew [:jfkthame]]

I've filed bug 642589 for the specific issue of DirectWrite subpixel antialiasing parameters, which apparently IE9 tweaks in some situations; we could try doing something similar. There's a patch and tryserver build there for experimentation.

That is just one possible aspect of the rather general/vague issue that "D2D and GDI text look different". It will not make them look the same, but it allows us to try fine-tuning the D2D rendering.

Comment 68

[Dão Gottwald [:dao]]

(In reply to comment #66)
> Created attachment 519631 [details]
> screenshot of IE9 and FF4 rendering on reddit
> 
> On my laptop, both IE9 and FF4 are using HW-accelerated dwrite text on
> reddit.com, [...] the vertical spacing differs,

Is there a bug filed on this, by the way? I've heard a web developer complain about the spacing in FF4 with DW being different from every other browser (notably FF3.6, FF4 w/o DW, IE9).

Comment 69

[Joe Drew (not getting mail)]

(In reply to comment #68)
> (In reply to comment #66)
> > Created attachment 519631 [details]
> > screenshot of IE9 and FF4 rendering on reddit
> > 
> > On my laptop, both IE9 and FF4 are using HW-accelerated dwrite text on
> > reddit.com, [...] the vertical spacing differs,
> 
> Is there a bug filed on this, by the way? I've heard a web developer complain
> about the spacing in FF4 with DW being different from every other browser
> (notably FF3.6, FF4 w/o DW, IE9).

I think this is bug 635640.

Comment 70

[Dão Gottwald [:dao]]

(In reply to comment #69)
> (In reply to comment #68)
> > (In reply to comment #66)
> > > Created attachment 519631 [details]
> > > screenshot of IE9 and FF4 rendering on reddit
> > > 
> > > On my laptop, both IE9 and FF4 are using HW-accelerated dwrite text on
> > > reddit.com, [...] the vertical spacing differs,
> > 
> > Is there a bug filed on this, by the way? I've heard a web developer complain
> > about the spacing in FF4 with DW being different from every other browser
> > (notably FF3.6, FF4 w/o DW, IE9).
> 
> I think this is bug 635640.

I get differences without bold rendering, though. Filed bug 643781.

Comment 71

[dets]

It is ridiculous that such an obvious CRITICAL bug have an "unconfirmed" status and Firefox 4 was released while this bug is not resolved. Only blind will not see the problem - font quality is not bad, it is horrible. Huge disservice to open source community and a shame for Mozilla developers. New "shiny" Firefox 4 is simply unusable now for many (or majority?) Windows 7 (only?) users until hardware acceleration is disabled and this is the first and the most obvious "advantage" of Firefox 4 users will see. Windows 7 x64, GeForce 8800GT, drivers 260.89. Guys, awake - it doesn't really matter how faster it is if the basic functionality doesn't work at all!!!

Comment 72

[Matthieu Rivaud]

Congrats, you've just sent an angry mail at 30+ users ^^,

Please note that you can get a much better experience using the ClearType tuner, and that bug 642589 has been filed to improve the "untuned experience".

Comment 73

[dets]

I already have Windows ClearType settings tuned because defaults didn't look very good for some reason (I guess they are optimized for mainstream cheap TN LCD monitors but I have an IPS one). Unfortunately, text in Firefox looks VERY different from text in ClearType tuner or any other application, so I'm not sure what I can tune, these settings seems to be ignored (or interpreted in a wrong way) by Firefox? It is also different compared to default Windows 7 font rendering. And by different I mean worse.

PS. Yes, I'm really upset by this bug.

Comment 74

[Jonathan Kew [:jfkthame]]

(In reply to comment #73)
> I already have Windows ClearType settings tuned because defaults didn't look
> very good for some reason (I guess they are optimized for mainstream cheap TN
> LCD monitors but I have an IPS one). Unfortunately, text in Firefox looks VERY
> different from text in ClearType tuner or any other application, so I'm not
> sure what I can tune, these settings seems to be ignored (or interpreted in a
> wrong way) by Firefox? It is also different compared to default Windows 7 font
> rendering. And by different I mean worse.

From the comments I've seen, I think the results vary greatly between different systems, and it's not clear why that is. Could you post a screenshot comparing the rendering of a page in FF4 and IE9 (where both browsers are using hw-accelerated rendering; check that IE9 is _not_ using one of its older "compatibility" modes), and also details of your configuration (in particular, the Graphics section from about:support).

Comment 75

[mvtodevnull]

Attachment: Firefox 4 and IE 9 font-rendering after cleartype tuning

The attachment shows font-rendering in FF4 and IE9 with hw acceleration on and ClearType tuner having been used. The ClearType tuner helped to turn extremely blurry fonts in Firefox 4 RC (as in my previous attachment) into slightly blurry fonts and I assumed the reason for the remaining perceived blurriness was just an artifact of being used to GDI+ font-rendering. However, having now tested IE9 with hw accel on, I can say font-rendering in Firefox 4 is still significantly worse.

Here is the graphics section of about:support:
Adapter Description ATI Radeon HD 5800 Series
Vendor ID 1002
Device ID 6899
Adapter RAM 1024
Adapter Drivers aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Driver Version 8.821.0.0
Driver Date 1-26-2011
Direct2D Enabled true
DirectWrite Enabled true (6.1.7601.17563, font cache 8.52 MB)
WebGL Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
GPU Accelerated Windows 1/1 Direct3D 10

Comment 76

[dets]

Attachment: Font rendering in FF4 with HW accel. on, of and tuned in "Anti-Aliasing Tuner"

I don't have IE9 and think I can't upgrade to it right now because I'm not sure how compatible will be already installed plugins (from Canon printer driver - they are very useful for me for printing selected parts of web pages - and this is the only thing I use IE for). I created an image that contains screenshot from the options dialog in FF4 in 3 configurations (left to right): HW acceleration enabled, HW acceleration disabled and HW acceleration enabled and settings changed in Anti-Aliasing Tuner (https://addons.mozilla.org/en-us/firefox/addon/anti-aliasing-tuner/). Last two look very similar, the only obvious difference is the size of dialog that is bigger in accelerated case - it seems that line spacing is bigger if HW acceleration is enabled. Settings that I changed: Anti-Aliasing Mode -> ClearType and Rendering Mode -> GDI Classic.

about:support graphics section with add-on disabled:

Adapter Description        NVIDIA GeForce 8800 GT
Vendor ID        10de
Device ID        0611
Adapter RAM      512
Adapter Drivers  nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version   8.17.12.6089
Driver Date      10-8-2010
Direct2D Enabled true
DirectWrite Enabled        true (6.1.7601.17563, font cache n/a)
WebGL Renderer   Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
GPU Accelerated Windows    4/4 Direct3D 10

Comment 77

[Avi]

dets, what settings did you use in Anti-Aliasing tuner? I'm trying various settings, but I'm not even close. And your results look almost as good as HW acceleration off.

Comment 78

[Chris]

Hello, I'm a new voter for this bug as I'm currently unable to work with HW acceleration enabled due to the fonts in our backend environment being too scrambled up. The above mentioned Tuner didn't really provide any improvement.

Anyway, I noticed that you earlier said you had direct contact with the DirectWrite team over at Microsoft, and last year I came across a debate over the new Visual Studio 2010 DirectWrite feature and their user reported problems with the new rendering and readability.

They did find a fix suitable for the vast majority of cases where it would 'replicate' GDI rendering very accurately and I thought maybe that fix could be applied here as well. Please see http://blogs.msdn.com/b/text/archive/2010/03/05/additional-wpf-text-clarity-improvements.aspx for further information. They have a great blog and I believe it may provide some insight for folks here regarding this issue.

I hope this will be fixed in a future release of Firefox as I'm really fond of the HW acceleration trend as of late. Thanks for your time.

Comment 79

[Emanuel Hoogeveen [:ehoogeveen]]

At risk of adding additional noise to this bug, I think there's a serious trade-off here between subpixel positioning and text clarity, more so for some people than others. At this point I'm used to it, but I have good eyes and sit relatively close to a big monitor (the only problem I still have is with the address bar, where I get a very pronounced rainbow effect). For others, maybe the improved kerning just isn't worth it - and it would be nice to have a reasonably accessible option to switch to GDI-like positioning.

Bug 642589 adds an about:config option to change the gamma, contrast enhancement and cleartype levels used when calling CreateCustomRenderingParams - I believe the 'rendering mode' parameter could be used to switch to different positioning, though the measuring mode would have to be adjusted to match (I think). Something like this was already done to fix font rendering when Cleartype is disabled.

Comment 80

[dets]

In tuner add-on I just set ClearType + GDI Classic for both font sizes, didn't change anything else. Unfortunately this is not a solution because though results are _much_ better they still seem to be not exactly the same, it seems that under some conditions (especially small black text on white background) some additional coloration (purple) is present along the letters' edges + add-on causes annoying redrawing problems in FF GUI.

Comment 81

[skylerlaughs]

How hard is it to disable sub pixel positioning? I this something that we can get a test patch/build of? If the choice is between perfect shape and positioning vs. sharp readable text, I vote for the latter. At least as an advanced option. I have tuned the text settings for hours, but still find myself switching back to Chrome for the readability of the text.

Comment 82

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

This bug IS A MUST BLOCKER for a next release!
Only Firefox have this blurry and awful quality of the fonts compared to Chrome, Opera, Safari or even IE...

Comment 83

[VanHeflin]

Hi, I have been puzzling over a font-smoothing/blurring issue and am suspecting a bug similar to the one you speak of here or at https://bugzilla.mozilla.org/show_bug.cgi?id=503150.

My hope is to find out if my issue is an actual bug and identify it so I can follow the progress. Also, I've been tweaking CSS and font stuff for three days and if I knew it was a bug then I could stop obsessing. :)

Anyways, I describe the issue at support.mozilla.com, but it might belong at bugzilla instead:
https://support.mozilla.com/en-US/questions/795834

I found a simple way to show my issue. When I click and drag a styled link, the ghosted link is correctly aliased, while the original is improperly anti-aliased, ala: http://imgur.com/hFkd7.

Is this the same issue as you are discussing in this thread? If not, do you think this might need a new bug report--or maybe you know of this as a bug already and could refer me there.

Thanks for your help & sorry if this adds any noise to the queue.

Comment 84

[phi2x]

Microsoft has developped an interesting technology called "Pixel Snapping".
http://msdn.microsoft.com/en-us/library/aa970908.aspx

There is an interesting explanation about text rendering:
"Windows Presentation Foundation (WPF) always generates anti-aliased text, and if the text is static, the text will be pixel snapped. 
This helps sharpen the look of anti-aliased text by placing the glyphs directly on the pixel grid, providing clearer text. 
However, when Windows Presentation Foundation (WPF) detects any animation-like movement, such as scrolling, scaling, or animated translation, pixel snapping is turned off until the movement is complete. 
Once the animation or scrolling is movement is finished, pixel snapping is slowly animated back on."

I think having a similar technology bolted in Firefox would help tremendously with that issue.

Comment 85

[Cngevpxhaqrefpber]

Attachment: Top is with Direct2D disabled (gfx.direct2d.disabled = true); bottom is with Direct2D enabled (gfx.direct2d.disabled = false)

I'm experiencing this issue as well; attached is an image showing one example of the difference in text crispness with Direct2D enabled and with it disabled on my system.

Top is with Direct2D disabled (gfx.direct2d.disabled = true) and ClearType disabled; bottom is with Direct2D enabled (gfx.direct2d.disabled = false) and ClearType still disabled. In both cases the "use hardware acceleration where available" option is checked.

Fonts also look blurry/odd (even worse, actually) in FF4 when ClearType is enabled; but even if that weren't the case, I'd prefer to leave ClearType disabled on my system because when it's enabled, generally speaking text is blurry in most programs on my system, while if it's disabled text is very crisp in all programs.

Here's my hardware info from about:support:

Adapter Description: Intel(R) HD Graphics
Vendor ID: 8086
Device: ID0042
Adapter RAM: Unknown
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Driver Version: 8.15.10.2342
Driver Date: 3-25-2011
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7601.17563, font cache n/a)
WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
GPU Accelerated Windows: 1/1 Direct3D 10

Until this is resolved I'm going to have to keep Direct2D disabled.

Finally, I want to note that fonts appear blurry for me in IE9 too, albeit to a differing degree.

Comment 86

[Martin Kliehm]

Confirming the bug. With hardware acceleration enabled sub-pixel rendering of text is slightly different, thus the text-size will differ, also the padding. This results in displaced text on a button instead of vertically centered text. Without hardware acceleration the result is identical to other browsers.

This is a show-stopper for me, because I can't develop with hardware acceleration that results in a different rendering than all other browsers.

Comment 87

[Matthieu Rivaud]

FWIW, you probably were developing on platforms with slightly different font rendering and font metrics already (Linux vs Windows vs Mac) ...

One should never assume pixel perfect compatibility between platforms, even w/o hardware acceleration or whatever. I saw too many sites that looked poor in linux because no fall-back font was defined and layout wasn't proportional with font metrics (no use of ems whatsoever).

That said, there already is a bug on the matter, and Mozillians are considering the change : bug #643781

Comment 88

[Martin Kliehm]

(In reply to comment #87)
> One should never assume pixel perfect compatibility between platforms, even
> w/o hardware acceleration or whatever.

I agree, and we've abandoned pixel perfect layout long ago. Still I expect a text to be vertically centered the same in every browser, because it looks borked otherwise. I'm glad the issue will be addressed soon.

Comment 89

[Matthieu Rivaud]

(In reply to comment #88)
> I agree, and we've abandoned pixel perfect layout long ago. Still I expect a
> text to be vertically centered the same in every browser, because it looks
> borked otherwise. I'm glad the issue will be addressed soon.

You may want to file a bug for this specific issue (or search for an existing one on that particular matter). I would expect the button to have different size (height) based on text rendering and padding, but not the inner text to be badly centered ... This feels like a different bug to me and should probably treated as such (bug #643781 has not seen much activity, and is still in discussion - it may not qualify for your vision of "addressed soon").

Comment 90

[Will]

This is definitely still a problem in FF4, 5 & 6. I posted on the Mozilla forum about it here:  https://support.mozilla.com/en-US/questions/796757
Includes screenshots there, but in a nutshell, the hardware acceleration causes the font to take up more space, thus throwing off the page (text gets shifted, scrollbar gets added, etc). I haven't seen this problem in any other browser, and all looked fine prior to FF4. This really does need to be addressed...  Soon?

Comment 91

[Adam Łyskawa]

@Bas Schouten:
"3% of unhappines" is the reason to not care about quality? What a great news for competition. Opera and Chrome are really great browsers and against all odds they CAN render text properly on bad, naughty Windows 7. Google Chrome happens to be also the fastest browser, with almost as many extensions available. So - again - it can't be done?

What's more - font rendering problems occured also in previous versions on Linux, which affected other Mozilla based products like Komodo. Please, don't say display driver is bad, or one or another operating system component is bad. There are applications which can use subpixel rendering correctly so I think it is not impossible.

If new versions are released and reported bug is unfixed again and again - something is wrong.

We don't have this problem on Linux, but we don't have real hardware acceleration there too. Again - in can be done in games and screensavers - but it's another story.

The "bright side" is IE9 has exactly the same problem too. If it's a bug in Windows, then we need a workaround for this bug.

Comment 93

[Bas Schouten (:bas.schouten)]

(In reply to Adam Łyskawa from comment #91)
> @Bas Schouten:
> "3% of unhappines" is the reason to not care about quality? What a great
> news for competition. Opera and Chrome are really great browsers and against
> all odds they CAN render text properly on bad, naughty Windows 7. Google
> Chrome happens to be also the fastest browser, with almost as many
> extensions available. So - again - it can't be done?

If you look at actual benchmarks Chrome is actually only faster in some. Opera and Chrome also do not use content hardware acceleration on Windows 7. So they do not render using the DirectWrite libraries.

Anyway, a lot of development on this topic has happened, and it is still actively being worked on. In particular we're currently surveying what font rendering styles people prefer and what to use where.

Comment 94

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

Chrome doesn't support subpixel rendering.

Comment 95

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

Er, subpixel layout, that is.

Comment 96

[Adam Łyskawa]

I mean subpixel hinting (at least it's called like this in GNOME), my mistake. I noticed the rendering glitch is mostly visible on bold fonts, especially Arial, best on dark blue text on white background. You can see red or purple artifacts on sides of some vertical lines belonging to font. On this page - it's slightly visible on links.

Comment 97

[Rob Tonsan]

It's NOT the issue what it supports and what not...
It also NOT the issue what it uses to render fonts and what not...

So argumentation that Opera and Chrome aren't support "blurry" Firefox rendering isn't logical...
They simply don't use this rendering because it's too buggy and blurry, can't you understand this ?
Even Microsoft don't use it in his systems...

Comment 98

[Bas Schouten (:bas.schouten)]

(In reply to Rob Tonsan from comment #97)
> Even Microsoft don't use it in his systems...

Umm... yes they do... tried IE9? Or Live Messenger? Or Windows Photo Gallery... anyway.. the list is pretty long.

Comment 99

[Rob Tonsan]

(In reply to Bas Schouten (:bas) from comment #98)
> Umm... yes they do... tried IE9? Or Live Messenger? Or Windows Photo
> Gallery... anyway.. the list is pretty long.

I'm not talking about minor programs like Live Messenger or Windows Photo Gallery...
And I also don't have installed IE9, why would I ?
All this programs are not defaults one and even if they will be, who cares... should we go in this blurry and bugged rendering ? I don't think so...

Looks like only Mozilla devs didn't understand this. I care about it and want to change this **** behavior about supporting this rendering. Other ppl don't care and will choose other alternative like Chrome. Look how Firefox usage is lowering when Firefox 4 was released...

Comment 100

[Slava]

(In reply to Bas Schouten (:bas) from comment #98)
> Umm... yes they do... tried IE9? Or Live Messenger? Or Windows Photo
> Gallery... anyway.. the list is pretty long.

Ehm! These look like excuses for you to leave it how it is now!?

Clarification:

It is not a small cosmetic issue in the corner of some never-seen options dialog. It is a MAJOR bug that affects ALL fonts on ALL webpages, including ALL the browser text, decreasing user's ability to do the 1 (and almost only) task he uses a browser for: read text.

Come on! Stop arguing and start realizing! 

(p.s. I have turned off HA and suffering performance to see readable text. If there was no such option or if I didn't know how to turn it off, I would be commenting this bug from chrome. Do you really think I'm the only one?)

Comment 101

[Csaba Kozák [:WonderCsabo]]

You don't have to turn off HWA, just set gfx.font_rendering.cleartype_params.rendering_mode variable to 2 in about:config. With that, you achieve "the old" whole pixel rendering with HWA (which looks terribly aliased IMHO).

Comment 102

[Will]

It's not just the quality of the text that is at issue, unfortunately. In HA mode, the amount of space that the text takes up is also affected. In my previous post here I linked to a Mozilla forum page where I posted screenshots of my site showing the difference between HA and non-HA and how it affected a box (adding a scrollbar) and caused other text to drop down a line, etc, which had up until the new HA feature never been an issue in any other browser for my site, ever, and is still only an issue in FF.

As a site maintainer, my problem is that my users are going to see these "bugs" when using FF with its default settings on any OS that supports HA. I can't get around this (if at all) on my site without screwing up the display for everyone else. So, truth be told, if it were up to me I'd prefer either to see HA turned off by default until this issue is fixed, or at least in the meantime have the affected font settings set for their pre-FF4 defaults.

Comment 103

[Adam Łyskawa]

Hey, dude, this saves the day :) But interesting point is that in your configuration mode -1 looks better than 2. In my FF - mode 2 gives way better text.
My configuration is: Windows 7 x64, Radeon 4870, ClearType on, LCD display.

Comment 104

[Rob Tonsan]

(In reply to Csaba Kozák [:WonderCsabo] from comment #101)
> You don't have to turn off HWA, just set
> gfx.font_rendering.cleartype_params.rendering_mode variable to 2 in
> about:config. With that, you achieve "the old" whole pixel rendering with
> HWA (which looks terribly aliased IMHO).

And you will think that for example a simple user will use an advanced about:config with odd warning on the start to change this behavior ?
How he will know this ? From this tracker ? Dont' be funny, it's black magic like DOS or Linux like command-line for this user. He will simply change browser to normal one.

Comment 105

[Bas Schouten (:bas.schouten)]

(In reply to Slava from comment #100)
> (In reply to Bas Schouten (:bas) from comment #98)
> > Umm... yes they do... tried IE9? Or Live Messenger? Or Windows Photo
> > Gallery... anyway.. the list is pretty long.
> 
> Ehm! These look like excuses for you to leave it how it is now!?
> 
> Clarification:
> 
> It is not a small cosmetic issue in the corner of some never-seen options
> dialog. It is a MAJOR bug that affects ALL fonts on ALL webpages, including
> ALL the browser text, decreasing user's ability to do the 1 (and almost
> only) task he uses a browser for: read text.
> 
> Come on! Stop arguing and start realizing! 
> 
> (p.s. I have turned off HA and suffering performance to see readable text.
> If there was no such option or if I didn't know how to turn it off, I would
> be commenting this bug from chrome. Do you really think I'm the only one?)

And rather than act on personal preferences or gut feelings, John Daggett is currently realizing an extensive survey that will examine preferences for different rendering methods across a wide variety of fonts, font-sizes and systems.

Based on the information he gathers, we will make decisions on which fonts will be rendered through what methods, so that we satisfy the most wide group of users (the fact is, some people will always be unhappy). We've already based on early feedback switched some fonts to 'GDI style' rendering for upcoming versions where we believe there's a clear majority which prefers that. (I've got that switched off because I find the GDI rendering terribly distracting)

(In reply to Adam Łyskawa from comment #103)
> Hey, dude, this saves the day :) But interesting point is that in your
> configuration mode -1 looks better than 2. In my FF - mode 2 gives way
> better text.
> My configuration is: Windows 7 x64, Radeon 4870, ClearType on, LCD display.

There's two problems here:

1. DirectWrite isn't completely consistent across platforms.
2. People's preferences differ extremely on these things, want you might say looks 'much clearer', I might say looks aliased and hinted in a terrible manner. People need to learn that on this subject, their 'perception' of 'better' is not the absolute truth.

Comment 106

[Bas Schouten (:bas.schouten)]

(In reply to Will from comment #102)
> It's not just the quality of the text that is at issue, unfortunately. In HA
> mode, the amount of space that the text takes up is also affected. In my
> previous post here I linked to a Mozilla forum page where I posted
> screenshots of my site showing the difference between HA and non-HA and how
> it affected a box (adding a scrollbar) and caused other text to drop down a
> line, etc, which had up until the new HA feature never been an issue in any
> other browser for my site, ever, and is still only an issue in FF.

In general your site being dependent on text metrics so strongly is a 'problem' in general since it means font updates could also break your site. I find it hard to believe the differences in metrics are so big that a good design would actually change layout considerably.

Comment 107

[Will]

(In reply to Bas Schouten (:bas) from comment #106)
> (In reply to Will from comment #102)
> > It's not just the quality of the text that is at issue, unfortunately. In HA
> > mode, the amount of space that the text takes up is also affected. In my
> > previous post here I linked to a Mozilla forum page where I posted
> > screenshots of my site showing the difference between HA and non-HA and how
> > it affected a box (adding a scrollbar) and caused other text to drop down a
> > line, etc, which had up until the new HA feature never been an issue in any
> > other browser for my site, ever, and is still only an issue in FF.
> 
> In general your site being dependent on text metrics so strongly is a
> 'problem' in general since it means font updates could also break your site.
> I find it hard to believe the differences in metrics are so big that a good
> design would actually change layout considerably.

Actually no, really, the "problem" is that the site displays fine in EVERY other browser except FF4+. Site developers are sometimes required to work within certain design constraints (like fixed font sizes) for the sake of visual consistency across all browsers and at the customer's behest. Please don't blame valid code when it's the browser that is at fault. If it were merely a matter of changing some CSS around, fine, no problem--I've done that before, especially where IE is concerned; up until now FF had never been a problem. Maybe it would be easier to just tell all our users "Firefox 4/5/6 is broken, don't use them for our site"? Sorry if I sound a tad heated about this, but "blaming the victim" is bound to elicit such a response.

Comment 108

[Bas Schouten (:bas.schouten)]

(In reply to Will from comment #107)
> (In reply to Bas Schouten (:bas) from comment #106)
> > (In reply to Will from comment #102)
> > > It's not just the quality of the text that is at issue, unfortunately. In HA
> > > mode, the amount of space that the text takes up is also affected. In my
> > > previous post here I linked to a Mozilla forum page where I posted
> > > screenshots of my site showing the difference between HA and non-HA and how
> > > it affected a box (adding a scrollbar) and caused other text to drop down a
> > > line, etc, which had up until the new HA feature never been an issue in any
> > > other browser for my site, ever, and is still only an issue in FF.
> > 
> > In general your site being dependent on text metrics so strongly is a
> > 'problem' in general since it means font updates could also break your site.
> > I find it hard to believe the differences in metrics are so big that a good
> > design would actually change layout considerably.
> 
> Actually no, really, the "problem" is that the site displays fine in EVERY
> other browser except FF4+. Site developers are sometimes required to work
> within certain design constraints (like fixed font sizes) for the sake of
> visual consistency across all browsers and at the customer's behest. Please
> don't blame valid code when it's the browser that is at fault. If it were
> merely a matter of changing some CSS around, fine, no problem--I've done
> that before, especially where IE is concerned; up until now FF had never
> been a problem. Maybe it would be easier to just tell all our users "Firefox
> 4/5/6 is broken, don't use them for our site"? Sorry if I sound a tad heated
> about this, but "blaming the victim" is bound to elicit such a response.

Are we talking about a fixed-width font here?

Comment 109

[Will]

It's Verdana. Pretty standard stuff...

Comment 110

[Adam Łyskawa]

@Bas Schouten:
"People need to learn that on this subject, their 'perception' of 'better' is not the absolute truth." - is there really the absolute truth? I'm not sure.

I found that Windows 7 and GNOME have some settings to tweak subpixel hinting (including turning off subpixel hinting and use grayscale AA instead). On Windows you have lots of other preferences based on text sample selection. I tried to play with this, but default setting seemed the best one.
Apple Safari renders fonts differently, even on Windows. This is what I call "too much AA". The fonts are too soft, exactly like with "soft" Photoshop setting. In GIMP we can choose "font hinting". In GIMP, Photoshop and GNOME there is one option, which does exactly the same: "full hinting". This is what I call perfect (for readibility). One could complain the font is too sharp, but never aliased or distorted. Always readable. This can be achieved using subpixel hiting or grayscale hinting. SPH always gives a small amount of color artifacts, it has to, but it's unnoticeable (at least it should be).
Maybe everyone has own preference for font rendering and hinting method - but this should be configurable. The best - system-wide. It makes no sense to configure font rendering for each application. So I think Mozilla should render fonts in a manner most of the system components do. On Windows - DirectWrite is not the case. Windows UI is not rendered this way. Most applications don't use this method. There are a few exceptions (like IE9) - and those cause bug reports like this one.

I think the bug we are talking of is not a bug in Mozilla, but it's a bug in DirectWrite (or it's subcomponent). I think it tries to apply hinting on already hinted fonts which produces visible color artifacts. This is not question of someone's preference - this is just a bug (because there IS objectively proper algorithm of subpixel hinting, the one without visible artifacts on any font).

Since DW is buggy, and the problem affects some display drivers - Mozilla should not use it. And all complaining will stop.

Comment 111

[Bas Schouten (:bas.schouten)]

(In reply to Adam Łyskawa from comment #110)
> Since DW is buggy, and the problem affects some display drivers - Mozilla
> should not use it. And all complaining will stop.

I realize I may very well be a minority, but I do disprove this statement - I'd complain very loud, I -very strongly- prefer DWrite rendering to GDI text rendering. The lack of sub-pixel positioning makes words look terrible with GDI rendering to me.

Comment 112

[Csaba Kozák [:WonderCsabo]]

+1. Also, i see much people on forums share the same thoughts: "first, DW looked terribly to me, now i get used to it, and GDI is strange." 
I'm very excited about the survey,; don't you know, Bas, when we can get the results?

Comment 113

[Bas Schouten (:bas.schouten)]

(In reply to Will from comment #109)
> It's Verdana. Pretty standard stuff...

Not fixed-width though, I'm no font layout expert but from what I understand that means you can't rely on the metrics for page layout.

The fact nobody -exposed- this issue yet doesn't necessarily mean the browser that exposes it is at fault.

Comment 114

[Adam Łyskawa]

Do you find the rendering in other browsers worse?

Comment 115

[Bas Schouten (:bas.schouten)]

(In reply to Adam Łyskawa from comment #114)
> Do you find the rendering in other browsers worse?

I do. Well, except IE9 when it isn't in compatibility mode for <=IE8.

Comment 116

[Will]

(In reply to Bas Schouten (:bas) from comment #113)
> (In reply to Will from comment #109)
> > It's Verdana. Pretty standard stuff...
> 
> Not fixed-width though, I'm no font layout expert but from what I understand
> that means you can't rely on the metrics for page layout.
> 
> The fact nobody -exposed- this issue yet doesn't necessarily mean the
> browser that exposes it is at fault.

That could be true, although IE9 supposedly uses hardware acceleration and the text appears just as it should in that browser (never mind that IE9 is broken in MANY other ways).

Anyway, Verdana is such a commonly used font that other people are bound to (and have) experienced this issue. I don't think switching fonts is necessarily the best solution. If forced to choose, I myself would opt for what has been working up until now. If I knew that everyone would absolutely be viewing my pages with HA turned on from now on, then maybe I'd be more inclined to change fonts. But I think we both know the reality is that not everyone will be using Firefox, with or without HA (many XP users still out there for example).

Comment 117

[Matthieu Rivaud]

FWIW, it has been discussed in bug 643781, bug 601152 and bug 628601 (some of these bugs are already referenced as blocking this one).

@Will : as a fellow web developer, I am quite surprised you still rely on consistent font metrics between browsers/platforms/devices. On linux, mac and even more so mobile devices (smartphones, tablets), the font rendering system is not the same as in Windows, and even exact same fonts can have different metrics. And most fonts do not even exist consistently for all platforms (Verdana for one is a Windows specific font, with sometimes near-perfect replacements for some platforms ; that's why the font-family CSS property is so useful).

Comment 118

[Petter]

@Matthieu and others: This is about an annoying problem in FF. You can discuss Will's web developing elsewhere.

Comment 119

[Rob Tonsan]

(In reply to Bas Schouten (:bas) from comment #111)
> (In reply to Adam Łyskawa from comment #110)
> > Since DW is buggy, and the problem affects some display drivers - Mozilla
> > should not use it. And all complaining will stop.
> 
> I realize I may very well be a minority, but I do disprove this statement -
> I'd complain very loud, I -very strongly- prefer DWrite rendering to GDI
> text rendering. The lack of sub-pixel positioning makes words look terrible
> with GDI rendering to me.

(In reply to Csaba Kozák [:WonderCsabo] from comment #112)
> +1. Also, i see much people on forums share the same thoughts: "first, DW
> looked terribly to me, now i get used to it, and GDI is strange." 
> I'm very excited about the survey,; don't you know, Bas, when we can get the
> results?

But more ppl complaining about it, not supports it...
And if you think that normal GDI rendering looks bad, so how did you use other programs in Windows, lol...

Comment 120

[Rich Parker]

Attachment: monoprice.com in Firefox 6.0.2, Chrome 13.0.782.215, Opera 11.51, and IE 9.0.8112.16421

I'm adding my own screen shots to the mix.  It sounds like the same problem reported here.  Notice that in the dollar amount "$11.17", "$1" looks right but "1.17" appears bold.  The "Ships Today..." and "Please note..." text also looks much nicer in the other three browsers.  Disabling Direct2D fixes the problem.

Comment 121

[Rich Parker]

Was this addressed in Firefox 7?  The text looks a lot better now with Direct2D enabled and rendering_mode set to the default of -1, though the kerning still isn't right in some places.

Comment 122

[Phoenix]

That may be result of fixing https://bugzilla.mozilla.org/show_bug.cgi?id=660448 and https://bugzilla.mozilla.org/show_bug.cgi?id=661471

Comment 123

[Will]

It's looking a lot better in FF7 on my pages (as referenced elsewhere). It does still seem to be affecting vertical space, however; I'm still getting that scrollbar at my top left menu in HA mode, whereas I don't get it in non-HA mode nor in any other browser...

Comment 125

[Will]

(In reply to Will from comment #123)
> It's looking a lot better in FF7 on my pages (as referenced elsewhere). It
> does still seem to be affecting vertical space, however; I'm still getting
> that scrollbar at my top left menu in HA mode, whereas I don't get it in
> non-HA mode nor in any other browser...

Just an FYI for anyone following up on this, I've removed one of the breaks in the aforementioned menu in an attempt to get rid of the scrollbar on my own. The scrollbar as mentioned doesn't show up in *any* other browser or version but FF7, so there definitely seems to be a difference in FF7 as to how it is rendering vertical space in HA mode, perhaps only for line breaks. Anyway, I didn't want anyone looking at my existing page and thing the FF7 issue was necessarily "fixed" or non-existent anymore. I'd suggest maybe some testing with line break rendering in HA mode to see if that is indeed the issue. Thanks for listening.  :)

Comment 126

[Phoenix]

Found that in case of nested <b> tags on page with hardware acceleration enabled I get twice bolder text, is this supposed behavior?

Comment 127

[Phoenix]

Attachment: Small testcase for double <b> tags

Comment 128

[Jonathan Kew [:jfkthame]]

(In reply to Phoenix from comment #126)
> Found that in case of nested <b> tags on page with hardware acceleration
> enabled I get twice bolder text, is this supposed behavior?

Yes, as the Arial family (under DirectWrite) has not only a "bold" weight, but also an even-bolder "black" weight. <b> is styled as "bolder", so you get bolder text than the surrounding regular face. And if you use <b> again within the <b> element, you get even-bolder text, if possible.

The fact that on some platforms and/or with some fonts, there is only support for two weights (regular and bold), and so the nested <b> doesn't actually appear any bolder than its surrounding text, is just a limitation of those environments.

Comment 129

[Phoenix]

(In reply to Jonathan Kew (:jfkthame) from comment #128)
Thanks for explanation, but then it's strange that IE9 under DirectWrite doesn't draw text twice bolder...

Comment 130

[Jonathan Kew [:jfkthame]]

(In reply to Phoenix from comment #129)
> (In reply to Jonathan Kew (:jfkthame) from comment #128)
> Thanks for explanation, but then it's strange that IE9 under DirectWrite
> doesn't draw text twice bolder...

It does, if it's running in "IE9 Standards Mode". (Your testcase above seems to get handled in "quirks" mode by default, which results in GDI-like font management.)

Comment 131

[M. H.]

Here is a zoomed example of the horrible blurred medium size fonts (this is Arial, nothing fancy): http://maettig.com/media/firefox-font-rendering-sucks.png

This bug exists since Firefox 4.0 and never changed since then. It's the same on all Windows versions. Obviously some position calculation is broken. Firefox does not render characters on full pixels but on half pixels. Since half pixels do not exist it creates a mess of gray pixels.

Please note that ClearType is turned off on all my machines (I'm getting sick of the colored mess it produces).

Turning hardware acceleration off in Firefox fixes the problem (at least for Arial, verdana and some other system fonts, but not for all fonts). The "Anti-Aliasing Tuner" mentioned above does not help. It looks the same or worse, no matter what setting I try.

Such blurred mess can be seen everywhere, for example on your own "firstrun" and "whatsnew" pages: http://www.mozilla.org/de/firefox/9.0.1/whatsnew/

Comment 132

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

(In reply to M. H. from comment #131)
> Please note that ClearType is turned off on all my machines (I'm getting
> sick of the colored mess it produces).

If you turn it on, does the problem go away?

If that's the problem, please file a separate bug about the situation where Cleartype is turned off.

Comment 133

[M. H.]

Attachment: Comparison of blurry fonts with ClearType on/off and acceleration on/off

Comment 134

[M. H.]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #132)
> If you turn it on, does the problem go away?

No. It's more or less the same. The font rendering is annoying blurry with hardware acceleration turned on, no matter if ClearType is turned on or off. The difference is, with ClearType turned on the blurry pixels around the letters are colored, with ClearType off they are gray.

This bug is about ugly font rendering with hardware acceleration enabled. I can confirm this for all cases, with ClearType on and off.

With ClearType enabled the accelerated rendering is a lot more blurry and a lot more colorful compared to what ClearType looks like in every other program.

With ClearType disabled the accelerated rendering is a complete mess of gray pixels, as said before. I really don't understand why this experimental, bogus feature was enabled by default in 4.0 and never fixed since then. Am I the only user in the world wide web that cares about reading text?

Comparison: https://bugzilla.mozilla.org/attachment.cgi?id=589469

The machine where I created the screenshots (but as said it's the same problem on all Windows machines, even XP): Windows 7, Aero enabled, Firefox 9.0.1 (but as said, this bug never changed since 4.0).

Comment 135

[Slava]

@M.H. 
You're definately not the only one concerned (and hihgly frustrated) about this issue. Just google related terms or read the comments above and you'll notice how many are there.

I've been tracking loads of information about this issue since 4.0, and as far as I can tell this issue is still not fixed because some responsible developer(s) actually 'likes' the blurry rendering and is refusing to understand how this scares users off their product. But, we can't blame the supplier when you get the product for free. We can only report and ask to fix.

So, you're better off disabling HWA. Font rendering is not the only issue in HWA.

Comment 136

[Bas Schouten (:bas.schouten)]

(In reply to Slava from comment #135)
> @M.H. 
> You're definately not the only one concerned (and hihgly frustrated) about
> this issue. Just google related terms or read the comments above and you'll
> notice how many are there.
> 
> I've been tracking loads of information about this issue since 4.0, and as
> far as I can tell this issue is still not fixed because some responsible
> developer(s) actually 'likes' the blurry rendering and is refusing to
> understand how this scares users off their product. But, we can't blame the
> supplier when you get the product for free. We can only report and ask to
> fix.

I think you're probably confused, other developers than myself did an extensive survey amongst a large group of users to determine which fonts are preferred in natural symmetric rendering (new with DirectWrite), and which fonts are preferred in GDI classic rendering.

Based on the results of this survey I believe a number of fonts(/sizes of fonts) were switched to use GDI classic rendering, and several were left at natural symmetric rendering. I also believe something was done with the DirectWrite enhanced contrast setting, but I'm not 100% sure what.

Anyway, my comment may be slightly inaccurate, but the general thought is correct. Of course this is thew internet so you're completely free to voice any opinion you like :), but the reality is that the choice was made to use the new font rendering system Microsoft developed out of the box. When concerns were raised we chose to first to quantitive analysis of people's preferences, before making random changes. There's additional settings that can be tweaked also from about:config, to keep HWA on, but use different rendering modes for fonts, you could see if you like one of the other rendering modes better.

Comment 137

[Bas Schouten (:bas.schouten)]

(In reply to M. H. from comment #134)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment
> #132)
> Comparison: https://bugzilla.mozilla.org/attachment.cgi?id=589469
> 
> The machine where I created the screenshots (but as said it's the same
> problem on all Windows machines, even XP): Windows 7, Aero enabled, Firefox
> 9.0.1 (but as said, this bug never changed since 4.0).

Are you -sure- it's the same on Windows XP? We don't use hardware acceleration for text rendering on windows XP. DirectWrite doesn't even exist there so GDI would be the only available font renderer.

Comment 138

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

(In reply to M. H. from comment #134)
> This bug is about ugly font rendering with hardware acceleration enabled. I
> can confirm this for all cases, with ClearType on and off.

It seems to me that in the Cleartype-on case, you simply don't like the DirectWrite Cleartype rendering, even when it's in "GDI mode". I'm not sure if there's anything that can be done about that other than turning off hardware acceleration.

In the Cleartype-off case, it looks like we're failing to align the glyphs on pixel boundaries. That seems like a genuine Firefox bug that we can fix to everyone's satisfaction. So I'd encourage you to report it as a separate bug rather than get lost in this bug's myriad issues.

> With ClearType enabled the accelerated rendering is a lot more blurry and a
> lot more colorful compared to what ClearType looks like in every other
> program.

Except for IE9 I presume, which also uses DirectWrite when in standards mode.

> Am I the only user in the world wide web that cares about reading text?

No, but your preferences are very different to most users'. Most users haven't disabled Cleartype, for example.

Comment 139

[Phoenix]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #138)
> No, but your preferences are very different to most users'. Most users
> haven't disabled Cleartype, for example.
By default, Windows XP uses some "general" font anti-aliasing and ClearType is disabled

Comment 140

[Petter]

(In reply to Phoenix from comment #139)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment
> #138)
> > No, but your preferences are very different to most users'. Most users
> > haven't disabled Cleartype, for example.
> By default, Windows XP uses some "general" font anti-aliasing and ClearType
> is disabled
Windows XP is over 10 years old.

Comment 141

[Phoenix]

(In reply to Petter from comment #140)
> Windows XP is over 10 years old.
And still got largest market share. I don't think that ignoring 43% of market (data from netmarketshare.com) is wise idea.
Anyway, under Windows 7 hardware acceleration still looks crappy with wrong text positioning even with ClearType

Comment 142

[Rich Parker]

Regardless of the default setting in XP vs. 7, it's not necessarily the general "preference".  Most users take whatever Microsoft sticks in their faces without question even when it's not the best option (Internet Explorer vs. Netscape *cough*).

I also refused to switch to ClearType until a few months ago.  I was actually pushed into it because of the ugly font rendering problems introduced in one of the recent versions (5?) of Firefox.  Although I'm mostly (51%) happy that I switched, ClearType still looks bad with rainbow effects in some places, even after being tuned.  Maybe if my vision wasn't 20/15 I wouldn't care.  Anyway, Firefox shouldn't be the only browser that looks like **** with ClearType off.

Comment 143

[Bas Schouten (:bas.schouten)]

(In reply to Quatrix from comment #142)
> Regardless of the default setting in XP vs. 7, it's not necessarily the
> general "preference".  Most users take whatever Microsoft sticks in their
> faces without question even when it's not the best option (Internet Explorer
> vs. Netscape *cough*).

I'd argue there's a general consensus subpixel anti-aliasing is a good thing, both amongst Mac and Windows users.

> I also refused to switch to ClearType until a few months ago.  I was
> actually pushed into it because of the ugly font rendering problems
> introduced in one of the recent versions (5?) of Firefox.  Although I'm
> mostly (51%) happy that I switched, ClearType still looks bad with rainbow
> effects in some places, even after being tuned.  Maybe if my vision wasn't
> 20/15 I wouldn't care.  Anyway, Firefox shouldn't be the only browser that
> looks like **** with ClearType off.

Yes, with cleartype off we have issues due to pixel alignment, that I can confirm (or at least, that's what it looks like).

Comment 144

[M. H.]

(In reply to Bas Schouten (:bas) from comment #137)
> Are you -sure- it's the same on Windows XP? We don't use hardware
> acceleration for text rendering on windows XP.

You are right. On Windows XP no hardware acceleration is used, so the checkbox in the settings is useless (which leads to another bug, "don't confuse people with an useless checkbox").

To let you know, I created bug 719410: "Blurry font rendering with ClearType disabled and hardware acceleration enabled".

Comment 145

[Csaba Kozák [:WonderCsabo]]

You are wrong, layers acceleration can be used on XP, too.

Comment 146

[Joe Drew (not getting mail)]

Hardware acceleration is used on Windows XP (layers are composited using Direct3D 9), but text itself isn't drawn using hardware acceleration (DirectWrite) but software (GDI).

Comment 147

[M. H.]

(In reply to Csaba Kozák [:WonderCsabo] from comment #145)
> You are wrong, layers acceleration can be used on XP, too.

I don't care what you belief, I have eyes, I can see it for myself. On Windows XP (latest service pack, latest DirectX 9, latest graphics drivers) the "use hardware acceleration if available" setting does nothing. Nothing is accelerated. Text is rendered with good old, well-readable GDI.

Comment 148

[Joe Drew (not getting mail)]

M.H., please stop commenting about this. Hardware acceleration is entirely different from GDI text rendering.

Comment 149

[M. H.]

(In reply to Joe Drew (:JOEDREW!) from comment #148)
> M.H., please stop commenting about this. Hardware acceleration is entirely
> different from GDI text rendering.

What is this supposed to mean? Shut up and use an other browser?

This bug is called "Text using hardware acceleration looks inferior to and considerably different from text with acceleration disabled and on other browsers" and that's exactly what thousands of people (see the comments above) are complaining about. It's insanely blurred with ClearType disabled (see bug 719410) but also bad with ClearType enabled (which is this bug). I'm very sorry but I don't understand why Mozilla focuses on using Firefox as a playground for experimental features while at the same time core features like displaying text are broken since version 4.

(In reply to Bas Schouten (:bas) from comment #136)
> other developers than myself did an
> extensive survey amongst a large group of users to determine which fonts are
> preferred in [what] rendering.

What survey? What people participated in that survey? From what countries? How where these people selected? How did you distinguish people who really care about readability from people who didn't care and just clicked what looked pleasant and cushy?

> There's additional settings that
> can be tweaked also from about:config, to keep HWA on, but use different
> rendering modes for fonts

To use a famous quote: "Don't Make Me Think". There is no setting in the configuration dialog except for disabling all hardware acceleration. I will not mess around with some strange numbers in about:config. Same problem with the "Anti-Aliasing Tuner". It's mess of confusing checkboxes. Most of them seem to do nothing.

Comment 150

[Will]

I can't be the only one reading through all of this (and having experienced the bug first-hand) to think that maybe it would be best for the next Firefox build to *disable* hardware acceleration by default until this issue is fixed?

It seems counter-intuitive (to me, anyway) to automatically enable a feature for everybody that A) is buggy, and B) isn't required to run the program. Most basic users aren't going to know to disable hardware acceleration themselves if the text on their screens is blurry, etc, nor will they care (or even know about) the benefits of hardware acceleration. Advanced users on the other hand would be more likely to know about the HA and be inclined to realize that it's something they can enable (and if the bug doesn't affect them, can leave on). Given Firefox's market share, it would be incorrect to presume that ALL Firefox users are advanced enough to know the issues here.

It also seems like there's a fair bit of denial going on from the programmer side of things, which may be natural, but is not helpful.

But that's just my 2 cents.

Comment 151

[Phoenix]

Attachment: Fx Nightly unaccelerated vs IE 10 vs Fx Nightly accelerated

Another 1.5 year passed, Firefox still render pages incorrectly with hardware acceleration, still nobody to fix this?

Comment 152

[Will]

(In reply to Phoenix from comment #151)
> Created attachment 759106 [details]
> Fx Nightly unaccelerated vs IE 10 vs Fx Nightly accelerated
> 
> Another 1.5 year passed, Firefox still render pages incorrectly with
> hardware acceleration, still nobody to fix this?

Considering they've been given ample time, and ample examples and screenshots and explanations showing the issue, the only reason I can think of why it hasn't been fixed yet is that they just don't care. They're too busy trying to make Firefox look as much like Chrome as possible. I guess that's where their priorities lie.

Comment 153

[Sarex]

Firefox shows incorrect fonts with hardware acceleration enabled: https://support.mozilla.org/en-US/questions/1023761

Why developers don't fix this bug?

Comment 154

[Gian-Carlo Pascutto [:gcp]]

(In reply to Sarex from comment #153)
> Firefox shows incorrect fonts with hardware acceleration enabled:
> https://support.mozilla.org/en-US/questions/1023761
> 
> Why developers don't fix this bug?

This is a [meta] bug, which means it's a collection of a number of different issues that cause the result that is the bug title.

Most of the problems here that were in Firefox *are* fixed: the font rendering is done by the operating system and generally speaking, font rendering on Windows will always look different when done in fully accelerated mode. The "inferior" part of this bug has improved a lot since the initial reporting after fixes from Microsoft (improved font hinting) and tweaks to Firefox to change the default rendering mode for some fonts to a different mode if a survey indicated most users preferred that. Other browsers have now caught up and also added hardware accelerated text rendering (e.g Chrome 37) and so look more similar to Firefox's font rendering than they did 4 years ago.
 
If there are *specific* problems remaining, you should file *specific* new bugs with a description exactly what's wrong. The link posted is titled "incorrect fonts" but from a cursory look just means "I preferred the old way" and that's not something any developer will be able to act upon without more information.

Comment 155

[tyl]

bump

Ticking "Use hardware acceleration when available" results in washed out graphics.

This problem in firefox 64.0.1 x64, windows 10x64

Comment 157

[MarjaE]

Also affects MacOS.

Comment 158

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.