Closed Bug 652141 Opened 14 years ago Closed 13 years ago

Default setting for gfx.font_rendering.cleartype_params.rendering_mode should be GDI Classic to provide clearer/sharper text (reverts the "blurriness" introduced by Fx4)

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WONTFIX
Tracking Flags:
Tracking Status
firefox6 - ---
firefox7 - ---

People

(Reporter: Virtual, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(6 keywords)

Attachments

(9 files)

-1-Firefox default
146.90 KB, image/png
Details
0-default
146.86 KB, image/png
Details
1-aliased
122.71 KB, image/png
Details
2-GDI Classic
135.55 KB, image/png
Details
3-GDI Natural
135.66 KB, image/png
Details
4-Natural
145.08 KB, image/png
Details
5-Natural Symmetric
184.12 KB, image/png
Details
disabled hardware acceleration
136.33 KB, image/png
Details
patch, set dwrite rendering mode to GDI Classic by default
20.37 KB, patch
roc
: review-
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:6.0a1) Gecko/20110421 Firefox/6.0a1 Build Identifier: Default setting for gfx.font_rendering.cleartype_params.rendering_mode should be "2" (GDI Classic) instead of "-1" to provide clear text like in Chromium or Internet Explorer. Reproducible: Always
(In reply to comment #0) > Default setting for gfx.font_rendering.cleartype_params.rendering_mode should > be "2" (GDI Classic) instead of "-1" to provide clear text like in Chromium or > Internet Explorer. "Like in .... Internet Explorer" is an oversimplification. IE9 switches between different rendering modes depending whether it decides to use an IE8 or earlier "compatibility" mode, or its "native" IE9 mode. In the default IE9 mode, for standards-compliant pages, it uses DW/D2D rendering that is quite similar to Fx4's.
Attachment #527802 - Attachment description: chardware acceleration → disabled hardware acceleration
In my case "2" causes some fonts to render pretty lousy. I use "5" to achieve the best results. To assume "2" should be the default might be unwise.
(In reply to comment #10) > In my case "2" causes some fonts to render pretty lousy. I use "5" to achieve > the best results. To assume "2" should be the default might be unwise. Can you post some screenshots? Will be nice to see how it renders on different PCs
You could see how it's rendering but you wouldn't see how it _looks_ on his display. For example what if he has a display with BGR subpixel arrangement or vertically rotated? Not to mention contrast and gamma… There is a reason why there is the ClearType tuner.
Dexter, do you have high DPI? Because that would have an effect on the relative merits of classic vs. natural...
First, some history: http://www.joelonsoftware.com/items/2007/06/12.html It comes down to a choice between typeface fidelity/precision/accuracy and readability. "Natural" rendering tries to preserve the intent and fidelity of the typeface, and that often results in glyph positions falling on a fraction of a pixel and stroke lines that straddle pixels. "Classic" (GDI) rendering snaps strokes and positions to whole pixel boundaries, thus producing clearer, crisper text with superior contrast, but at the cost of distorting the shape and size of the glyphs. At small font sizes (but not too small; 8pt-12pt at 96dpi), fidelity and clarity are mutually exclusive. At these sizes, where the lines/strokes of a glyph are approximately pixel-sized, there WILL be a loss of contrast and clarity when you use subpixel metrics. You can fiddle with the contrast and other parameters to try to mitigate that, but that tradeoff will always be there. Microsoft has, until very recently, favored the clarity and readability of whole-pixel metrics, and I think that it makes the a lot of sense. What do most people use the web for? Reading. Reading news articles, blogs, twitter messages, forum posts, source code, etc. And it makes sense to optimize for this dominant activity. I know that when I'm reading pages of code, I couldn't care less about whether each glyph was rendered exactly as the typeface designer had intended. What I do care about is that the text has good contrast, is sharp, and crisp so that it is easier on my eyes. When Microsoft switched Visual Studio 2010 to use the Windows Presentation Foundation (which also uses natural rendering), there was a major backlash that prompted Microsoft to spin a second beta with classic GDI-style rendering (the final version uses this GDI-style rendering). And although this is only anecdotal evidence, I have seen a lot of people in various forums and boards who have complained about IE9's and Firefox 4's text as being "blurry". Also, GDI-style rendering is more consistent with the overall Windows experience. Most of Windows uses GDI-style rendering: Windows Explorer, the taskbar, etc. The only major exception is IE9 as DirectWrite or WPF-based applications are pretty rare in the Windows ecosystem. Finally, I do realize that there are many cases where "natural" rendering is more readable. Specifically, for extremely small font sizes with strokes that are so thin that sub-pixel metrics will help a lot with clarity and readability (and where whole-pixel metrics of the GDI will result in an unreadable mush) and for large font sizes where the strokes are significantly thicker than a pixel, and thus there is nothing to be gained from pixel-grid conformity. I think that the best course of action would be to set GDI mode for fonts of a certain size (e.g., the equivalent of 7pt-13pt at 96dpi; note that this means that for high-DPI users, the point range would be lower because what we really care about is the width of a stroke relative to the pixel). FWIW, this sort of segmentation, where different algorithms are applied based on the font size, has been used for over 15 years by MSFT to determine how to handle font smoothing.
Version: unspecified → Trunk
(In reply to comment #8) > "Like in .... Internet Explorer" is an oversimplification. IE9 switches between > different rendering modes depending whether it decides to use an IE8 or earlier > "compatibility" mode, or its "native" IE9 mode. In the default IE9 mode, for > standards-compliant pages, it uses DW/D2D rendering that is quite similar to > Fx4's. So it only applies to Chrome in 100% and IE partially. (In reply to comment #10) > In my case "2" causes some fonts to render pretty lousy. I use "5" to achieve > the best results. To assume "2" should be the default might be unwise. But value "2" is like Firefox render fonts before landing hardware acceleration. Clear and sharp. Also all Windows GUI render fonts this way. So maybe too many Anti-Aliasing Tuner customization without restoring to default ? (In reply to comment #12) > You could see how it's rendering but you wouldn't see how it _looks_ on his > display. For example what if he has a display with BGR subpixel arrangement or > vertically rotated? Not to mention contrast and gamma… > There is a reason why there is the ClearType tuner. But monitor settings didn't help to get rid of this blurry fonts.
Summary: Default setting for gfx.font_rendering.cleartype_params.rendering_mode should be "2" (GDI Classic) instead of "-1" to provide clear text → Default setting for gfx.font_rendering.cleartype_params.rendering_mode should be "2" (GDI Classic) instead of "-1" to provide clear and sharp text like in Firefox without HW Acc
"But value "2" is like Firefox render fonts before landing hardware acceleration. Clear and sharp. Also all Windows GUI render fonts this way. So maybe too many Anti-Aliasing Tuner customization without restoring to default ?" no it isn't,
(In reply to comment #16) > no it isn't, Yes it is. Look on my screenshots to see that fonts with "2" are the same like without HW Acc. Looks pixel-perfect in comparison. And still waiting for answer for author of the post.
Just wanted to chime in here ... gfx.font_rendering.cleartype_params.rendering_mode of 2 looks identical to Chrome and pre-IE9 font rendering here. And yes, I do think this should be the new default. I don't think most people are trying to finalize graphic design work in their browser. I do think most people want fonts that can be read quickly. Also ... much thanks to the developers for providing people like me the option, even if it's not the default.
(As a point of clarification, -1 simply means "default", so the default pref shouldn't change from -1 to 2; instead, the meaning/behavior of the -1 default pref should be changed.) As I explained in the final three paragraphs of comment 14, I think that to do this right, we should apply classic "pixel-snapped" GDI-style rendering to a certain range of glyph sizes. One option would be to abandon the idea that -1 necessarily needs to perfectly correspond with one of the 0-5 settings; we could let -1 mean "DirectWrite default (0) at all sizes except [range], where we use GDI classic (2)." Alternatively, we could break the render_mode setting into three separate settings: tiny, small, and large, and have -1 correspond with 0 for tiny/large and 2 for small.
Summary: Default setting for gfx.font_rendering.cleartype_params.rendering_mode should be "2" (GDI Classic) instead of "-1" to provide clear and sharp text like in Firefox without HW Acc → Default setting for gfx.font_rendering.cleartype_params.rendering_mode should be GDI Classic to provide clearer/sharper text (reverts the "blurriness" introduced by Fx4)
OS: All → Windows 7
This isn't a regression from Fx5 to Fx6, so it doesn't need to be tracked for fx6.
tracking-firefox6: ? → -
Yep I know, but it's "regression" from 3.6 to 4.0, and even if patch will land, the first stable with it will be 6.0.
Because there have been questions: I don't see any reason why this has to be tracked for Fx6 in particular. DirectWrite rendering was introduced way back in Fx4, after all. :) We should totally work on ways to make DW better/more acceptable, and if that lands for Fx6 all the better, but there will always be another train.
I'm going to override myself on tracking-firefox6:- this, because release drivers may indeed want to track this bug. I don't think it needs addressing in any particular Firefox release, though.
tracking-firefox6: - → ?
(In reply to comment #14) > Microsoft has, until very recently, favored the clarity and readability of > whole-pixel metrics, and I think that it makes the a lot of sense. What do > most people use the web for? Reading. Reading news articles, blogs, twitter > messages, forum posts, source code, etc. Sometimes also for printing. Which made me think, are there any plans for a separate setting for controlling font rendering in the print preview tab? > I know that when I'm reading pages of code, I couldn't > care less about whether each glyph was rendered exactly as the typeface > designer had intended. Since code is generally displayed using monospaced fonts you also wouldn't see the improvements on kerning, etc. > Also, GDI-style rendering is more consistent with the overall Windows > experience. Most of Windows uses GDI-style rendering: Windows Explorer, the > taskbar, etc. The only major exception is IE9 as DirectWrite or WPF-based > applications are pretty rare in the Windows ecosystem. There is also Valve Steam and the applications in the Windows Live Essentials 2011 pack. > (e.g., the equivalent of 7pt-13pt at 96dpi; note that this means > that for high-DPI users, the point range would be lower because what we really > care about is the width of a stroke relative to the pixel). Good idea, although it somehow sounds absurd that people who have already have a higher resolution get the benefit of the 'tripled' horizontal resolution earlier. > FWIW, this sort of segmentation, where different algorithms are applied based > on the font size, has been used for over 15 years by MSFT to determine how to > handle font smoothing. This is also the case how it DirectWrite implemented in IE9 concering bitmap display of CJK fonts. Plus vertical anti-aliasing is also not used for the smaller font sizes.
In response to Comment 13 I do run at 120DPI. With the proliferation of large screen LCD's does anyone run at normal (96DPI)? Also I have to still use Zoom in Fx on most pages. I prefer using Test Zoom over Page Zoom so images arenot blurry. However text Zoom can screw up text alignment on pages. So each Zoom method has a tradeoff. I've found that certain fonts cause me the most problems. These being Arial, Times New Roman, and Georgia. To remedy this I did a Font Substitute in my Windows 7 Registry for these fonts. I substituted them with free fonts I found on the Web. They are the Liberation series of fonts. I then had to change the font options in Fx to point to the corresponding Liberation Fonts. I use an addon called Font Replacer to change a few more fonts to Arial which really are now Liberation Sans because of the Font Substitution in my Registry. Finally I still use Anti-Aliasing Tuner and set everything to Cleartype/Natual Symmetric. Setting the Rendering Pref in Fx to 5 does not provide the clarity that A-A Tuner does. Bottom line.... All my fonts look great. But really... should I have to go through all of this to get good looking fonts?
tracking-firefox flags aren't for suggesting something is important. If you think it's important, work with the leads of that module to get it prioritized.
tracking-firefox6: ? → -
Any chance this can make info Firefox 6? Branching is in a week. For fast workaround we can use for default GDI Classic, instead of what Kai Liu propose.
Blocks: 635490
This is a band-aid to revert text rendering to GDI-style by default, until we have better data to base decisions on, and more sophisticated support for choosing an appropriate rendering mode on a per-font basis (e.g, based on size, font technology, user vs system fonts, specific list of ClearType-optimized fonts, etc). Until we have the code to support such option(s) in place and tested, and have collected adequate data about user perceptions, the safest course to deal with the current user unhappiness w.r.t. the appearance of fonts (perceived as a regression in Fx4 compared to 3.x) is to revert to pre-Fx4-style rendering. To do this without sacrificing h/w acceleration, we need to set DWrite to use "GDI Classic" rendering mode by default. Making this change triggers about a dozen reftest failures (and a couple of "unexpected" passes). I've reviewed the failure logs, and none of them are visually important; they're due to imperceptible subpixel discrepancies at glyph edges. Hence, in addition to the one-line pref change, the patch includes the necessary tweaks to reftests and manifests in order to keep the tree green. It sucks that we have to do this, but I think we should; then we can work towards reintroducing "native" (subpixel-positioned, natural-antialiased) DWrite font rendering in a more controlled and conservative way for the contexts where it provides the most benefit.
Attachment #536575 - Flags: review?(roc)
Since -1 just means "default", wouldn't it make more sense to keep the default settings at -1 and instead change the mapping of -1 from 4 to 2?
(In reply to comment #29) > Since -1 just means "default", wouldn't it make more sense to keep the > default settings at -1 and instead change the mapping of -1 from 4 to 2? -1 means "gecko should let dwrite do its default thing, don't specify a mode explicitly", so it just uses the setting from CreateRenderingParams(). It isn't explicitly mapped to 4 anywhere in our code, AFAIR. We could change that, of course, to map -1 to 2, but that would involve a (minor) code change rather than just modifying a preference value, and I don't see any real advantage.
What about the users who prefer the current rendering, wouldn't this be a regression for them then? Also, if you indeed go back to the old rendering, you should then probably inform the users who care about web development why the IE Test Drive demos http://ie.microsoft.com/testdrive/Performance/TextSizeAnimated/Default.html http://ie.microsoft.com/testdrive/Performance/TextJustificationAnimated/Default.html and http://ie.microsoft.com/testdrive/Performance/ScrollingText/Default.xhtml don't look as smooth anymore.
(In reply to comment #31) > What about the users who prefer the current rendering, wouldn't this be a > regression for them then? Yes, it would. There doesn't seem to be any way to ship something that will please everyone, as we don't have code that can automatically detect the user's (possibly subconscious) reactions to font rendering. What is clear, though, is that there's a lot of dissatisfaction with the change in text when migrating from Fx3 to Fx4. Until we have a more finely-tuned solution ready to deploy, reverting to text that looks more like it did in Fx3.6 seems to be the most prudent option.
Comment on attachment 536575 [details] [diff] [review] patch, set dwrite rendering mode to GDI Classic by default Review of attachment 536575 [details] [diff] [review]: ----------------------------------------------------------------- While I personally agree this is the right thing to do, we don't have a consensus that this is the right thing to do at this time, so I don't think I can approve this, much as I'd like to.
Attachment #536575 - Flags: review?(roc) → review-
Who's missing from the consensus? Can those people please express themselves here?
Bug 642589 got checked in. Please grab the next nightly build to see if things have improved. (In reply to comment #34) > Who's missing from the consensus? Can those people please express themselves > here? John Daggett, Joe Drew, Jeff Muizelaar and Bas Schouten, at least, aare all against a wholesale switch to GDI_CLASSIC.
(In reply to comment #35) > Bug 642589 got checked in. Please grab the next nightly build to see if > things have improved. Bug 661471, I assume.
Like always... No consensus within dev team = users suffer Forcing some fonts in GDI Classic is a tiny workaround for this whole problem and this not fix more than 5-10% "blurry" fonts on the sites because of poor chosen default rendering... If we made this change, why not use GDI Classic for all fonts? Or at least for fonts with size less than 16 for example...
(In reply to comment #37) > Forcing some fonts in GDI Classic is a tiny workaround for this whole > problem and this not fix more than 5-10% "blurry" fonts on the sites because > of poor chosen default rendering... What fonts other than Arial, Courier New, Tahoma, Trebuchet MS, and Verdana do think need the GDI Classic treatment?
I ask the other hand. Which fonts don't need GDI Classic treatment and looks better in default Firefox rendering ? I see no one. Because 99,9% of sites have fonts in size about 10-12. I saw some time ago on other bug report, html file with many fonts styles to test this. Unfortunately can't remember where. But still, all fonts look superior in GDI Classic rendering than default, at least in normal font size, not super duper hiper large. Why you guys so anti old good rendering and push this blurry massacre on users... I don't understand this...
BernesB@gmail.com, please do not nominate bugs for tracking without an explanation of why you think the release team should be paying attention to the bug. This issue has already been sufficiently addressed and there is no obvious change in this bug being proposed by the people responsible for this part of the product. Release drivers are not engineering management or module owners and you should not nominate bugs for release driver tracking because you are unhappy with the decisions made by the module team. Also, BernesB@gmail, your participation here is not helpful and if you continue with the approach you're using here and other bugs, you risk losing your Bugzilla privileges. I'd recommend you take a step back and consider carefully any further comments you make in Bugzilla and whether or not they're adding value to bugs.
tracking-firefox7: ? → -
I checked the survey and the special part of it is that the survey needs to change some configurations of the browser. If we want to release it on TestPilot, we can as following: (1) target at window users only; (2) ask them whether they want to participate in the font survey; (3) if yes, install an add-on which can automatically change the settings; (4) show them the survey link (as what we normally do for text survey). It should be do-able. I need to know what exactly the setting changes are, and host the survey online (probably on people.mozilla.com). :)
(In reply to comment #41) > I checked the survey and the special part of it is that the survey needs to > change some configurations of the browser. If we want to release it on > TestPilot, we can as following: (1) target at window users only; (2) ask > them whether they want to participate in the font survey; (3) if yes, > install an add-on which can automatically change the settings; (4) show them > the survey link (as what we normally do for text survey). > > It should be do-able. I need to know what exactly the setting changes are, > and host the survey online (probably on people.mozilla.com). > Oh! sorry I reply to the wrong bug ... > :) (In reply to comment #41) > I checked the survey and the special part of it is that the survey needs to > change some configurations of the browser. If we want to release it on > TestPilot, we can as following: (1) target at window users only; (2) ask > them whether they want to participate in the font survey; (3) if yes, > install an add-on which can automatically change the settings; (4) show them > the survey link (as what we normally do for text survey). > > It should be do-able. I need to know what exactly the setting changes are, > and host the survey online (probably on people.mozilla.com). > > :)
What's the status of fixing this bug? Any plans? At least make option somewhere near HW ACC ON/OFF setting to use mode "2" (GDI Classic).
(In reply to Rob Tonsan from comment #43) > What's the status of fixing this bug? I guess it's "wait and see how Bug 661471 is received by the general user-base". If it's received well (esp. by those who weren't happy with the DW rendering) then this one here might get WONTFIXed.
Personally i see no reson for this.Now we can set our own fonts that can be rendered with GDI Classic and i serously doubt Mozilla is going to force GDI classic on all fonts by default,thus effectively reverting to pre-4.0 rendering method. Besides most affected fonts are already in the new pref in Fx 6.0
I'm only just curious how end user like simple John will want to change something in advanced nightmare config like about:config without any help or info what one option means and change, even on Mozilla pages. It will be wise to provide option in GUI like style, not only for geeks, but also for normal people. Also I simply don't understand why devs pushing this not perfect rendering as default which cause many problems for users (just type "Firefox blur font" in google), while Chrome & Opera seems to understand this. Just finally see the reality and that the end users will swap their browsers with the one that isn't problematic, see how Firefox usage is lowering and Chrome is growing. It all started with Firefox 4 release and this blurry fonts. Just my 2 cents.
> Just finally see the reality and that the end users will swap their browsers > with the one that isn't problematic, see how Firefox usage is lowering and > Chrome is growing. It all started with Firefox 4 release and this blurry > fonts. > > Just my 2 cents. And my axe. :) If I hadn't found the magic about:config setting in my first foray into Google I'd be objecting to the new behavior as well. I use an LCD but I run with ClearType disabled on the (admittedly entirely subjective) grounds that it looks like ass. High-frequency content in glyph edges is an important visual cue IMO, and it doesn't deserve the jihad that's been waged against it over the years. Would it be reasonable for Firefox to check the Windows registry to see if the user has deliberately turned ClearType off, and inherit that behavior for the gfx.font_rendering.cleartype_params.rendering_mode==-1 case? Seems that this might be better than making your own guess at what the user considers the 'default'.
> Review of attachment 536575 [details] [diff] [review] [diff] [details] [review]: > ----------------------------------------------------------------- > > While I personally agree this is the right thing to do, we don't have a > consensus that this is the right thing to do at this time, so I don't think > I can approve this, much as I'd like to. Was there a consensus to change from the original font rendering (pre-fx4) to the new, blurry one, or was that an unforseen side-effect? I would consider this change a late bug-fix for blurry fonts. As far as I know, lots of users were very unhappy about that change, many were held back from upgrading to the current fx branch "because it makes your text blurry" and probably tens of thousands of users had to disable hardware acceleration because that was the only known fix for this issue. Changing this for e.g. Fx 7 would be a chance to get people to upgrade ("hey, the font blurryness has been finally fixed") Such tiny things can make the difference between happy users and "this browser totally sucks", as the first subjective impression is very important. This change should have been 4.0.1, IMHO.
Jan, please read what I wrote and linked to four comments earlier.
Firefox 8 and nothing happens. I voted for the bug and i hope i'm still a firefox user then. Can someone explains how i can get rid of that bug with your gfx.font_rendering.* parameters?
1. type "about:config" in address bar 2. search for "gfx.font_rendering.cleartype_params.rendering_mode" 3. change its parameter to "2" Also a good option will be creating near HW Acc ON/OFF option in Firefox menu, sth like "Use pre-Firefox 4/GDI rendering", to get old good fonts like in other programs and in system.
(In reply to Virtual_ManPL from comment #51) > Also a good option will be creating near HW Acc ON/OFF option in Firefox > menu, sth like "Use pre-Firefox 4/GDI rendering", to get old good fonts like > in other programs and in system. This would constitute its own bug. (In reply to R2KFoto from comment #50) > Firefox 8 and nothing happens. Since Firefox 7 GDI-like font rendering is used per default for the default Windows 7 UI font and some of the most used fonts on small font sizes, see bug 661471. Because of this, this bug here could be marked WONTFIX IMHO (maybe after doing some quick assessment on how successful bug 661471 was in reaching its goal).
"2" do not work (Win7 64, cleartype off) HW Acc Off is no alternative.
(In reply to R2KFoto from comment #53) > "2" do not work (Win7 64, cleartype off) > > HW Acc Off is no alternative. report bug please and post #ID, because "2" option should be identical like with HW Acc disabled
Bug 703625
Bumping this issue; I have been experiencing font blurriness in Firefox since 4.0, and it is still present in 9.0.1 (fixed locally by changing the rendering_mode setting to 2, though I understand that won't fix this for everybody). This is a very big usability issue for Firefox, as it makes reading a lot of text more difficult, and I reckon it is a contributory factor in users shifting away from Firefox to other browsers. So, would it be possible to get the priority of this issue elevated, i.e. such that it blocks future releases of Firefox until it is fixed?
Bug 661471 was implemented instead of changing this for all fonts at all sizes. If there are still issues, please file new bugs with screenshots (before and after whatever pref changes you have made), and CC me.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Joe, please look at comment 55.
Marking as VERIFIED WONTFIX as now Firefox render 99% cases properly, mostly due to bug 661471.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: