User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre If you write llllllllllllllllll to the address bar, it looks like a rainbow. Regression from the subpixel AA update (Bug 622482)? Reproducible: Always

To some extent this effect is unavoidable when using subpixel AA on a set of lines so closely spaced with subpixel distances between them. It is worsened however by incorrect gamma correction. We are working on a solution for the problem as I do believe it looks less than great, however I do not believe this is a hardblocker for release. I expect there to be at least something we can do before then though.

This is a screenshot taken in Beta 9 in content where the same font is used, showing even when correct gamma is applied (this is drawn with D2D), the rainbow effect is present, i.e. it's not completely avoidable when using subpixel positioning.

The colours used for the sub-pixel components seem to vary between drivers, in my experience ATI cards result in something resembling what GDI displays, and Nvidia cards result in a much lighter/smoother set of colours. That being said, the colours being used for chrome rendering are definitely wrong, and don't match the same text displayed in content. I don't know if it's the gamma or what but the results aren't pretty. about:support says the DirectWrite version is "6.1.7600.20781", but I don't know if that's the most up to date version (or if it'll even make a difference)

Yep, the different between the two rainbows in that picture, that's the gamma values.

(In reply to comment #2) > Created attachment 504342 [details] > Screenshot Beta 9 > > This is a screenshot taken in Beta 9 in content where the same font is used, > showing even when correct gamma is applied (this is drawn with D2D), the > rainbow effect is present, i.e. it's not completely avoidable when using > subpixel positioning. The rendering here is _much_ more "rainbow-y" than the version shown in the content of Alex's screenshot; it's a bit difficult to compare because of the colored background, but it looks much closer to Alex's chrome rendering, which (I would say) is not acceptable. Why are the colors in the two "content" versions so different?

The color tints seem to be far more noticeable on LED display, probably due to the huge contrast ratio. The users display might explain some of the different perceptions people have over the issue.

Just to add another data point, it looks pretty bad on my screen. I am using an ATI card and the rainbow effect is quite noticeable. In fact after a few minutes it makes my eyes hurt. Hardware & config for comparison: Windows 7 x64 ATI Radeon HD 4850 (Graphics) BIOS Version 011.008.000.000 (Graphics) BIOS Date 2009-01-06 ATI Drivers: Driver Packaging Version: 8.782-100930m-106921C-ATI Catalyst Version: 10.10 2D Driver Version: 8.01.01.1081 Direct3D Version: 8.14.10.0784

(In reply to comment #7) > Created attachment 504732 [details] > Example on the aerial firefighting wikipedia entry > > Just to add another data point, it looks pretty bad on my screen. I am using an > ATI card and the rainbow effect is quite noticeable. In fact after a few > minutes it makes my eyes hurt. > > Hardware & config for comparison: > Windows 7 x64 > ATI Radeon HD 4850 > (Graphics) BIOS Version 011.008.000.000 > (Graphics) BIOS Date 2009-01-06 > > ATI Drivers: > Driver Packaging Version: 8.782-100930m-106921C-ATI > Catalyst Version: 10.10 > 2D Driver Version: 8.01.01.1081 > Direct3D Version: 8.14.10.0784 Umm, this is an old build still using grayscale AA. As far as I can see the only cleartype here is normal sub-pixel AA rendering by DirectWrite.

Here's the exact same page using non-DirectWrite (GDI) rendering for comparison. In the examples, the URL was changed in the address bar to use an URL that shows much more pronounced differences (the Wikipedia URL is also rendered worse with DirectWrite but it is not as stark). After checking several pages, it looks like Arial and medium-to-small sans-serif fonts exhibit the worst behavior. In the UI, Segoe UI appears unnaturally thin and sparkly (rainbowy). Verdana is mostly unaffected. Serifs such as Georgia look different but are not as eye-fatiguing.

Wait, are you talking about the URL bar/browser chrome, or the page itself.

Talking about both. When I say "in the UI" (for Segoe UI), I am referring to the browser chrome, specifically dialog boxes and other stuff created using XUL. For everything else, the fonts have been viewed on actual webpages/stuff in the content area.

(In reply to comment #11) > Talking about both. > > When I say "in the UI" (for Segoe UI), I am referring to the browser chrome, > specifically dialog boxes and other stuff created using XUL. > > For everything else, the fonts have been viewed on actual webpages/stuff in the > content area. So, in the DWrite screenshot that you posted, there -is- no rainbow effect in browser chrome since it's an older build still using grayscale anti-aliasing for glyphs. (Mind you, this is the browser chrome, not dialog boxes or anything like that) In the content window, I can see some minor sub-pixel AA differences between GDI and DWrite due to GDI using hinted glyphs without sub-pixel glyph positioning, but nothing that looks gamma incorrect or like the rainbow effect that this bug is about. The effect you're seeing (of uneven subpixel color distribution due to subpixel glyph positioning in content) has been present since Beta 5.

This screenshot illustrates the difference between subpixel glyph positioning and hinted glyph metrics. If you pay attention to the 'i' in the upper GDI case, you'll notice that both 'i's get identical subpixel AA, simply because they're both positioned at pixel boundaries. In the DWrite case different 'i's experience different AA because they're aligned to different subpixels. This means if you have a lot of subsequent, identical glyphs you might get some minor rainbow effect due to non-homogenous density in lit subpixels. But this will average out statistically when diverse glyphs are used(as is normally the case). In these screenshots I can see no difference in the 'strength' of subpixel AA applied nor any significant different in color-fringing due to different AA in general. However this can be different on different monitors. You might want to try running the 'ClearType' tuner in your control panel to try and adapt the settings to your monitor.

Ok. First, to clarify, I am using the Release build of Firefox 4.0 beta 9 (4.0b9). Is that considered old--is there new rendering behavior on the trunk that solves at least some of these problems?

I did use the ClearType tuner to see if it would have an effect. While it affects the rest of Windows, somewhat bafflingly (or perhaps explainable by the Mozilla rendering code), I could not detect a perceptible difference between the Firefox renderings even when I cranked ClearType's settings way off from the baseline.

(In reply to comment #15) > I did use the ClearType tuner to see if it would have an effect. While it > affects the rest of Windows, somewhat bafflingly (or perhaps explainable by the > Mozilla rendering code), I could not detect a perceptible difference between > the Firefox renderings even when I cranked ClearType's settings way off from > the baseline. Hm, that suggests that (at least on your system), DirectWrite is not adhering to your system cleartype settings. Any chance you could test the IE9 beta? In any case, this bug is about a different effect on trunk introduces by recent patches.

Ok well, I did some background reading and it looks like we have several variables in play. Sorry I am kind of new to these rendering problems--bzbarsky just pointed me here since I was expressing general displeasure about the state of the rendering in b9. :) The attached screenshot (which sounds like it confirms existing b9 problems, rather than helps with the trunk) illustrates that the rainbow l has not gone away. Top left: Thunderbird 3 (plain GDI) Far right: Windows 7 Explorer (also, likely, plain GDI) DOM Inspector and center window: DirectWrite As you can see, it is true that the address bar does not have rainbow effects per-se. But, it does have a grayscale rainbow effect, like a diffraction grating. The rest of the chrome (in DOM Inspector, which is using Segoe UI) and the content area further illustrate.

(In reply to comment #16) > Hm, that suggests that (at least on your system), DirectWrite is not adhering > to your system cleartype settings. Any chance you could test the IE9 beta? I have IE9 beta running in a VM, but would rather not put it on my development machine. As far as the other variables in play: - graphics card - graphics driver (just updated to the latest ATI driver, the specifics of which are listed below--as you see from my latest screenshot, the driver does not fix the problem) - IE8 vs. IE9 beta - MS KB2454826 <http://support.microsoft.com/?kbid=2454826> which some on another forum were mentioning is supposed to improve the rendering situation - Windows 7 SP1, which should include MS KB2454826 and which appears to have been RTMed in the last four days - obviously, the precise build of Firefox ******* ATI Drivers: Driver Packaging Version: 8.801-101125a-109686E Catalyst Version: 10.12 2D Driver Version: 8.01.01.1105 Direct3D Version: 8.14.10.0798 ******* In order to provide more feedback on this before I turn my attention to other matters, what other patches and builds should I apply (except for IE9)? Also, what are the other bug ID numbers that I should be reporting these various problems under, if any?

(In reply to comment #17) > Created attachment 504760 [details] > Comparison of lllllllllllllllllllll in different rendering environments. > > Ok well, I did some background reading and it looks like we have several > variables in play. Sorry I am kind of new to these rendering problems--bzbarsky > just pointed me here since I was expressing general displeasure about the state > of the rendering in b9. :) > > The attached screenshot (which sounds like it confirms existing b9 problems, > rather than helps with the trunk) illustrates that the rainbow l has not gone > away. > Top left: Thunderbird 3 (plain GDI) > Far right: Windows 7 Explorer (also, likely, plain GDI) > DOM Inspector and center window: DirectWrite > > As you can see, it is true that the address bar does not have rainbow effects > per-se. But, it does have a grayscale rainbow effect, like a diffraction There is a non uniform pixel density distribution in the grayscale case, this is correct. As for the other environments, notice how in the GDI case it's yellow-ish (the pixel aligned position apparently causes a higher density of red and green pixels), and in the DWrite case it's a rainbow. Different people will have different objections to the different rendering situations. One would argue the none-uniform color effect in the subpixel positioning case is certainly more noticable, but I think by far outweighed by the advantages of subpixel positioning. You could raise a general bug on this but I don't think there's much that can be done, it's an inherent property of the display technology.

Well, it sounds like I'll just "leave it out there" now, since I've reported the bug/my experiences on the bug, and hopefully it was at least a little helpful. I guess my main request/plea is that, from a user experience standpoint, I would think that users would expect the same rendering behavior across all of their apps, including Firefox. Windows' ClearType technology may not be the greatest (as you point out, yellow-ish due to red and green pixels), but since all apps on Windows use the same settings, users get used to it and expect the same behavior out of the Windows experience.

(In reply to comment #20) > Well, it sounds like I'll just "leave it out there" now, since I've reported > the bug/my experiences on the bug, and hopefully it was at least a little > helpful. > > I guess my main request/plea is that, from a user experience standpoint, I > would think that users would expect the same rendering behavior across all of > their apps, including Firefox. Windows' ClearType technology may not be the > greatest (as you point out, yellow-ish due to red and green pixels), but since > all apps on Windows use the same settings, users get used to it and expect the > same behavior out of the Windows experience. I somewhat agree. Software is moving to DWrite, for example Windows Live applications now use DWrite (Windows Live Messenger for example), Steam uses it these days. IE9 will use it, etc. There's a transition, but there's not much we can do about it.

Bas can you explain why there is such a difference between the aliasing on the text between Firefox 4 with hardware acceleration enabled and Firefox 4 with acceleration disabled, IE9 RC, and Opera 11? The latter 3 differ slightly in shading, but form the exact same pattern of aliasing. See also attachment below (screenshot from mozillazine) that shows text at actual size looking much worse than on all other browsers http://forums.mozillazine.org/viewtopic.php?f=23&t=2060933&p=10437617#p10437617

Comments #22 and #23 are likely to be a different bug, probably something to do with font selection. Please file separately.

(In reply to comment #24) > Comments #22 and #23 are likely to be a different bug, probably something to do > with font selection. Please file separately. K , bug 635490 posted

no, seriously? such a major bug is not blocking final?

wontfix it plz, don't tease us.

To some extent, color fringing is inherent in ClearType subpixel anti-aliasing. Even with GDI Classic rendering, rainbox patterns will emerge in text containing a large number of closely spaced vertical stems: http://people.mozilla.org/~jdaggett/tests/cleartype-waterfall.html Note how the string "important pistilliferous military milliliter ililililil lllllll iiiiii IIIIIIII lilliputian Illuminating Schillerstein lellellel" renders with Arial or Trebuchet MS at 10px. Bug 661471 forces on GDI Classic rendering for UI fonts so to some extent users will see less of this than they would if DirectWrite natural rendering was used. For users who don't want DirectWrite rendering at all, they can now adjust the rendering mode using the gfx.font_rendering.cleartype_params prefs. Setting the rendering_mode pref to '2' will force GDI Classic rendering for all text, both UI and content text.

Is attachment 504349 [details] a separate bug then? I can understand colour fringing, but shouldn't it at least be consistent within the same window?

The exact colors would depend on the exact subpixel position of the text on the pixel grid, right?

(In reply to Boris Zbarsky (:bz) from comment #30) There are number of different subpixel positions shown in attachment 504349 [details], and the urlbar is consistently worse than content, so exact subpixel position seems very unlikely to explain the difference.

(In reply to Boris Zbarsky (:bz) from comment #30) > The exact colors would depend on the exact subpixel position of the text on > the pixel grid, right? It will depend on the font, size, the initial position of the text *and* your Cleartype settings (in particular, enhanced contrast and Cleartype level settings). If you're using trunk, GDI Classic rendering is used when rendering Segoe UI, the normal UI font, at small sizes. So URL bar text will show the same artifacts as seen in Firefox 3.6 or in Chrome. With Chrome, URL text is rendered at a larger size so you'll see less fringing there. You can see the effect of positioning if you look at the test case in comment 28, for every font, right after the 4 initial waterfall sequences you'll see 10 lines drawn in text at the same size. Each line has an additional 0.1px margin, so you can see the effect of sliding the text around. You can also experiment with this using the subpixel explorer tool I wrote: http://people.mozilla.org/~jdaggett/tests/subpixelexplorer.html Hit 'f' to change the font to Segoe UI, the up arrow to increase the font size and then use the left/right arrows to shift the text 1/10 of a pixel. Cleartype is inherently sensitive to edge cases like this, both in DirectWrite and in GDI, but more so in DirectWrite. If you're sensitive to the fringing, the best solution is to run the Cleartype tuner and carefully tune your system settings to turn down the Cleartype level. If you've run the Cleartype tuner before you can view your Cleartype settings in about:support under "ClearType Parameters".

(In reply to *I need to change my userid so it's less racist) from comment #27) > wontfix it plz, don't tease us. (In reply to John Daggett (:jtd) from comment #28) > Status: NEW ➔ RESOLVED > Resolution: --- ➔ WONTFIX bwahahah