Last Comment Bug 719410 - Blurry font rendering with ClearType disabled in Windows and hardware acceleration enabled in Firefox
: Blurry font rendering with ClearType disabled in Windows and hardware acceler...
Status: NEW
[leave open]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.mozilla.org/de/firefox/9.0...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-19 05:53 PST by M. H.
Modified: 2015-06-13 13:56 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Comparison of blurry fonts with ClearType on/off and acceleration on/off (40.33 KB, image/png)
2012-01-19 05:53 PST, M. H.
no flags Details
comparison of glyph rendering with cleartype disabled, pure-GDI vs D2D/DWrite vs GDI/DWrite (33.07 KB, image/png)
2012-01-25 04:54 PST, Jonathan Kew (:jfkthame)
no flags Details
patch, don't use subpixel AA under GDI/DW when cleartype is disabled (1.27 KB, patch)
2012-01-25 05:39 PST, Jonathan Kew (:jfkthame)
bas: review+
Details | Diff | Review
IE9 and Chrome rendering of the grayscale-AA sample (23.08 KB, image/png)
2012-01-25 06:54 PST, Jonathan Kew (:jfkthame)
no flags Details
Clear font rendering in IE 8, Opera 11 and Firefox 11 without hardware acceleration (15.31 KB, image/png)
2012-03-19 02:35 PDT, M. H.
no flags Details
how IE9 renders the same text (4.35 KB, image/png)
2012-03-19 03:09 PDT, Jonathan Kew (:jfkthame)
no flags Details
Blurry_mess_in_Firefox_22.png (143.24 KB, image/png)
2013-07-19 03:29 PDT, M. H.
no flags Details

Description M. H. 2012-01-19 05:53:20 PST
Created attachment 589844 [details]
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) 2012-01-24 08:47:25 PST
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) (Exited; email my personal email if necessary) 2012-01-24 13:30:14 PST
Either you or Bas need to own this; I think probably you...
Comment 3 Bas Schouten (:bas.schouten) 2012-01-24 13:34:09 PST
(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) 2012-01-25 04:47:53 PST
(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) 2012-01-25 04:54:55 PST
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.
Comment 6 Bas Schouten (:bas.schouten) 2012-01-25 05:28:35 PST
(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) 2012-01-25 05:39:03 PST
Created attachment 591434 [details] [diff] [review]
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) 2012-01-25 06:54:49 PST
Created attachment 591452 [details]
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) 2012-01-25 12:42:48 PST
(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) 2012-01-25 13:50:30 PST
(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) (Exited; email my personal email if necessary) 2012-02-13 00:43:11 PST
Any progress?
Comment 12 Jonathan Kew (:jfkthame) 2012-03-06 09:46:07 PST
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] 2012-03-07 02:35:18 PST
https://hg.mozilla.org/mozilla-central/rev/c5a5f5ad0691
Comment 14 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-03-18 18:26:07 PDT
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) (Exited; email my personal email if necessary) 2012-03-18 18:36:27 PDT
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. 2012-03-19 02:35:42 PDT
Created attachment 607090 [details]
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) (Exited; email my personal email if necessary) 2012-03-19 03:01:11 PDT
Only because you avoided testing IE9.
Comment 18 Jonathan Kew (:jfkthame) 2012-03-19 03:09:10 PDT
Created attachment 607098 [details]
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. 2012-03-19 09:34:37 PDT
(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 2012-07-22 17:59:56 PDT
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) (Exited; email my personal email if necessary) 2012-07-22 18:03:23 PDT
(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 2012-07-22 18:18:10 PDT
yes,

it is sharp aliased under IE9 with a CSS trick.
only FF is making problems
Comment 23 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-07-22 19:07:43 PDT
What CSS trick?
Comment 24 biz 2012-07-22 19:18:29 PDT
filter:none in style.
I can provide you a test page
Comment 25 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-07-22 20:33:24 PDT
A test page would be great.
Comment 26 Jonathan Kew (:jfkthame) 2012-07-23 03:22:30 PDT
(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) 2012-07-24 23:01:17 PDT
(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. 2013-01-04 08:24:10 PST
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) (Exited; email my personal email if necessary) 2013-01-04 23:21:45 PST
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 2013-01-05 04:12:38 PST
there is a CSS trick to avoid blurry fonts !
Comment 31 M. H. 2013-01-08 05:18:28 PST
(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 2013-01-08 07:00:20 PST
to avoid blurry fonts in FF
one solution :

USE .otf format!

it works
Comment 33 M. H. 2013-01-08 13:17:16 PST
(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 2013-03-23 12:18:45 PDT
>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. 2013-07-19 03:29:33 PDT
Created attachment 778400 [details]
Blurry_mess_in_Firefox_22.png

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

Note You need to log in before you can comment on or make changes to this bug.