719410 - Blurry font rendering with ClearType disabled in Windows and hardware acceleration enabled in Firefox

Status: NEW

(Core :: Graphics, defect)

Description

[M. H.]

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

As suggested in bug 635490 I'm posting this as a separate issue:

When ClearType is disabled in Windows 7 (I'm getting sick of the rainbow pixels it produces) and hardware acceleration is enabled in Firefox (which is the default) the font rendering is insanely blurred (see attached screenshot). This is true for all bold, medium and big sized fonts. The only exception are very small sized fonts which are not anti-aliased at all (this is an expected behavior with ClearType off).

Turning hardware acceleration off in Firefox fixes the problem.

The "Anti-Aliasing Tuner" does not help. It looks the same or worse, no matter what setting I try.

Obviously some position calculation is broken. Firefox does not align the glyphs on pixel boundaries. Instead all characters are aligned on _half_ pixels. Since half pixels do not exist, it creates a mess of gray pixels.

Such blurry fonts can be seen everywhere, for example on your own "firstrun" pages: http://www.mozilla.org/de/firefox/9.0/firstrun

Attached is a zoomed comparison of ClearType on/off and hardware acceleration on/off. The font is Arial, nothing fancy. Windows version is 7. It's the same in Vista. I'm not sure about XP. From what I remember I think it's the same.

Firefox version does not matter. This problem exists since 4.0 and never changed since then. And it's the reason why I'm stuck with Firefox 3. The font rendering is so fu**ed up since 4.0, the single problem described in this report is just the tip of the iceberg. See bug 635490 if you don't believe me.

Comment 1

[Jonathan Kew [:jfkthame]]

I'm confirming this: I see the same behavior on my Win7 laptop. When using D2D/DWrite with ClearType disabled (only grayscale anti-aliasing) the glyphs look like they're being rendered at half-pixel positions instead of snapped to the pixel grid, with the result that vertical stems (in particular) tend to look blurry on the sides, whereas under GDI they have sharply-defined edges.

I've traced the text-drawing code to confirm that we're calculating the exact same glyph metrics and positions under both GDI and DWrite; the glyph advances are being properly pixel-snapped, and the glyph positions that we end up passing to the cairo backend (e.g. once we reach cairo_surface_show_text_glyphs) are exact integer pixels.

So it seems like the problem must lie somewhere fairly deep in the cairo-D2D backend...

Comment 2

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

Either you or Bas need to own this; I think probably you...

Comment 3

[Bas Schouten (:bas.schouten)]

(In reply to Jonathan Kew (:jfkthame) from comment #1)
> I'm confirming this: I see the same behavior on my Win7 laptop. When using
> D2D/DWrite with ClearType disabled (only grayscale anti-aliasing) the glyphs
> look like they're being rendered at half-pixel positions instead of snapped
> to the pixel grid, with the result that vertical stems (in particular) tend
> to look blurry on the sides, whereas under GDI they have sharply-defined
> edges.
> 
> I've traced the text-drawing code to confirm that we're calculating the
> exact same glyph metrics and positions under both GDI and DWrite; the glyph
> advances are being properly pixel-snapped, and the glyph positions that we
> end up passing to the cairo backend (e.g. once we reach
> cairo_surface_show_text_glyphs) are exact integer pixels.
> 
> So it seems like the problem must lie somewhere fairly deep in the cairo-D2D
> backend...

The D2D backend does nothing particularly intelligent with the glyph positions, so it seems unlikely that it could affect the positioning. Possibly pixel-snapped positions do not result in nicely positioned/hinted glyphs?

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to Bas Schouten (:bas) from comment #3)
> The D2D backend does nothing particularly intelligent with the glyph
> positions, so it seems unlikely that it could affect the positioning.
> Possibly pixel-snapped positions do not result in nicely positioned/hinted
> glyphs?

Possibly so.... but they do under GDI, for the exact same font/glyphs/positions. I wonder whether in the Cleartype-disabled case, we may not be using the best combination of rendering parameters/options/etc.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: comparison of glyph rendering with cleartype disabled, pure-GDI vs D2D/DWrite vs GDI/DWrite

Enlarged screenshots comparing Arial Bold rendered without h/w acceleration (pure GDI), with h/w/a (D2D/DWrite), and without h/w/a but with DWrite explicitly enabled in about:config.

Note the consistent, sharp-edged vertical stems of "fir" in the left-hand (GDI) column, and the symmetrical exclamation point. Under D2D/DW (the centre column), most of the vertical edges have gray edges that make them look "blurry", and their positioning on the pixel grid varies: it looks as though the glyphs are not being hinted.

For comparison, I wanted to compare the rendering we get with DirectWrite fonts under GDI, although this is not a fully-supported combination. However, as the right-column shows, we actually render with subpixel AA in this case, even though ClearType is turned off in the Windows control panel. So that's a separate bug we ought to fix.

Comment 6

[Bas Schouten (:bas.schouten)]

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> Created attachment 591423 [details]
> comparison of glyph rendering with cleartype disabled, pure-GDI vs
> D2D/DWrite vs GDI/DWrite
> 
> Enlarged screenshots comparing Arial Bold rendered without h/w acceleration
> (pure GDI), with h/w/a (D2D/DWrite), and without h/w/a but with DWrite
> explicitly enabled in about:config.
> 
> Note the consistent, sharp-edged vertical stems of "fir" in the left-hand
> (GDI) column, and the symmetrical exclamation point. Under D2D/DW (the
> centre column), most of the vertical edges have gray edges that make them
> look "blurry", and their positioning on the pixel grid varies: it looks as
> though the glyphs are not being hinted.
> 
> For comparison, I wanted to compare the rendering we get with DirectWrite
> fonts under GDI, although this is not a fully-supported combination.
> However, as the right-column shows, we actually render with subpixel AA in
> this case, even though ClearType is turned off in the Windows control panel.
> So that's a separate bug we ought to fix.

That's a known bug but since in theory DirectWrite to GDI is not a supported combination it was never really addressed. It should only require a little copy-paste work from the D2D code path.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: patch, don't use subpixel AA under GDI/DW when cleartype is disabled

The primary cause of the subpixel-AA in the GDI/DW case, even when ClearType is supposed to be turned off, is that we pass DWRITE_MEASURING_MODE_NATURAL to DrawGlyphRun. Rather counter-intuitively (although it _is_ hinted at by the docs) this affects the _rendering_ mode used.

This patch seems to fix this issue, so that the GDI/DW case gives us results similar to D2D/DW (though not pixel-identical): we get grayscale-AA glyphs, but the stems are not nicely hinted to pixel edges the way they are under the legacy GDI-only backend.

So I think we should take this, as a step towards better understanding of the issue here, though it doesn't actually resolve the primary bug we're facing. Investigation continues...

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: IE9 and Chrome rendering of the grayscale-AA sample

Interestingly, IE9 exhibits similar "blurry" rendering when ClearType is disabled, as shown in the left-hand part of this screenshot. Note that this happens regardless of whether it's running in IE9 mode or in IE7 or IE8 compatibility modes. Perhaps this is an unavoidable consequence of using DirectWrite to handle fonts? Do we know which APIs IE9 uses in its "pre-IE9-compatibility" modes?

Chrome, on the other hand, renders properly-hinted glyphs, like Firefox's GDI rendering (right-hand part of this screenshot). Presumably it's not using DWrite at all?

Comment 9

[John Daggett (:jtd)]

(In reply to Jonathan Kew (:jfkthame) from comment #8)

> Interestingly, IE9 exhibits similar "blurry" rendering when ClearType is
> disabled, as shown in the left-hand part of this screenshot.

By blurry here you mean grayscale with the slight shading on vertical edges as in comment 1?

> Chrome, on the other hand, renders properly-hinted glyphs, like Firefox's
> GDI rendering (right-hand part of this screenshot). Presumably it's not
> using DWrite at all?

Chrome uses GDI and not DirectWrite.

Comment 10

[Jonathan Kew [:jfkthame]]

(In reply to John Daggett (:jtd) from comment #9)
> (In reply to Jonathan Kew (:jfkthame) from comment #8)
> 
> > Interestingly, IE9 exhibits similar "blurry" rendering when ClearType is
> > disabled, as shown in the left-hand part of this screenshot.
> 
> By blurry here you mean grayscale with the slight shading on vertical edges
> as in comment 1?

Yes - vertical edges which under GDI are sharp white/black transitions often have a column of gray pixels - and what should be identical vertical stems vary between glyphs depending how they happen to fall on the pixel grid. It looks as though hinting isn't being applied to the glyph outlines, or at best is being applied as if for the subpixel grid, not for the whole-pixel grid that applies to grayscale rendering.

I'm currently beginning to suspect this is a fundamental difference between the GDI and DW rasterizers, and perhaps the DW one simply doesn't offer a mode that would accurately emulate GDI grayscale rendering. But still experimenting.

Comment 11

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

Any progress?

Comment 12

[Jonathan Kew [:jfkthame]]

Not really. AFAICT, this seems to just be the way DirectWrite does grayscale antialiasing, and it's different from GDI. I tried tinkering with various parameters but can't persuade it to provide the same style of rendering.

Pushed the patch from comment 7, so that at least we don't render glyphs with subpixel AA when it's supposed to be turned off entirely; this gives us more consistent rendering between DW/GDI and DW/D2D. But it doesn't resolve the primary issue here - the DW grayscale glyphs apparently not using hinting in the way GDI does it.

https://hg.mozilla.org/integration/mozilla-inbound/rev/c5a5f5ad0691

* Please do not close when merging to m-c, as this does not fully resolve the issue. *

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/c5a5f5ad0691

Comment 14

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

Sucks, but in that case the only thing I can think of would be to build a GDI text-drawing path that works with D2D, and that would probably be super-slow since to get GDI subpixel AA right we'd have to read back from D2D all the time, and for that reason and because explicitly turning ClearType off is likely to be rare, I don't think it's worth it.

Comment 15

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

duh, of course subpixel AA doesn't matter for this case. So maybe we could draw grayscale GDI text and use it as a mask without totally destroying performance.

Still not convinced it's worth it.

Comment 16

[M. H.]

Attachment: Clear font rendering in IE 8, Opera 11 and Firefox 11 without hardware acceleration

I get the same crystal clear font rendering in all web browsers except Firefox with hardware acceleration enabled (see comparison). So please, please disable that sh**.

Comment 17

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

Only because you avoided testing IE9.

Comment 18

[Jonathan Kew [:jfkthame]]

Attachment: how IE9 renders the same text

As (for some reason - perhaps it would weaken your argument?) you didn't include IE9 in that comparison, I'm attaching a screenshot of its rendering. Note that it shows similar blurriness to Firefox. This seems to be a "feature" of DirectWrite when ClearType is disabled; I suspect it was not really intended to be used without subpixel antialiasing.

Comment 19

[M. H.]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #17)
> Only because you avoided testing IE9.

I try to avoid IE at all. In other words, I don't care. Broken font rendering in IE9 is no excuse for broken font rendering in Firefox.

By the way, I did an additional test with Opera 12 and the font rendering is pixel perfect even with hardware acceleration enabled (I know Opera 12 uses OpenGL).

Comment 20

[biz]

Hi,

I am using  @font-face to load fixedsys font with my webpages.
it works everywhere and I get a sharp aliased edge except for FIREFOX !
firefox (all versions) are adding blurry things on the side with colors not only grey...
it is very bad looking to the eye.
Why don't firefox put a CSS option to disable this horrible feature?
we should be able to load pixel fonts and not see them antialiased in weird colors on the edge.
when installing TTF font to my windows it works without antialiasing. but using @font-face make the font horrible antialiased and eye fatigue.

Have you got an idea how to remove this in CSS ?

Thanks

Comment 21

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

(In reply to biz from comment #20)
> it works everywhere and I get a sharp aliased edge except for FIREFOX !

Everywhere including IE9?

Comment 22

[biz]

yes,

it is sharp aliased under IE9 with a CSS trick.
only FF is making problems

Comment 23

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

What CSS trick?

Comment 24

[biz]

filter:none in style.
I can provide you a test page

Comment 25

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

A test page would be great.

Comment 26

[Jonathan Kew [:jfkthame]]

(In reply to biz from comment #24)
> filter:none in style.
> I can provide you a test page

Surely that's an IE9 bug - 'filter:none' should have no effect on rendering.

Comment 27

[John Daggett (:jtd)]

(In reply to biz from comment #20)

> I am using  @font-face to load fixedsys font with my webpages.
> it works everywhere and I get a sharp aliased edge except for FIREFOX !
> firefox (all versions) are adding blurry things on the side with colors not
> only grey...

Please file a separate bug for this with a testcase to illustrate what's not working correctly for you.

Comment 28

[M. H.]

It's 2013. 14 versions (Firefox 4 to 17) with the same blurry mess where I expect a readable font rendering. The most importand feature (in my opinion, obviously Mozilla does not agree) of the web browser is broken since 2 years. Any progress? Any plans?

Comment 29

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

So one thing we *could* do is, disable use of D2D text when Cleartype is disabled, since D2D doesn't handle that very well.

Comment 30

[biz]

there is a CSS trick to avoid blurry fonts !

Comment 31

[M. H.]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #29)
> So one thing we *could* do is, disable use of D2D text when Cleartype is
> disabled, since D2D doesn't handle that very well.

Yes, this would be nice, since the underlying problem seems to be a bug in DirectWrite (D2D). Currently I have to disable hardware acceleration in Firefox to fix the blurry fonts.

(In reply to biz from comment #30)
> there is a CSS trick to avoid blurry fonts !

I can't edit all websites in the world. This must be fixed in the browser.

Comment 32

[biz]

to avoid blurry fonts in FF
one solution :

USE .otf format!

it works

Comment 33

[M. H.]

(In reply to biz from comment #32)
> USE .otf format!

Again, I can't change the whole world wide web to use different CSS. Please stop posting such comments. Changing some CSS in my own websites does not help to fix a browser bug.

Comment 34

[nucrap]

>seems to be a bug in DirectWrite (D2D)
Sorry but that's ****. It is the same on Linux which uses freetype.

Comment 35

[M. H.]

Attachment: Blurry_mess_in_Firefox_22.png

Checking again after a while. Yes, it's still a blurry mess in Firefox 22.

Comment 36

[Revertron]

It's still a blurry mess in FF 58.0a1

Comment 37

[David Sacal]

Hi,
i'm still seeing on windows 10 x64 using the latest nightly (68.0a1 2019 05 07) and release (66.0.4) on the right menu with reddit's usernames (on reddit homepage) blurry fonts with clear type disabled so i marked 66 and 68 flags as affected.

Comment 38

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

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.