[karmic] Firefox 3.5 and openoffice do not stick to antialiasing render settings

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061204 GranParadiso/3.0a1

The dropdown menus at the top of each page have the text sorta fuzzy looking with red/blue tints around the edges of some of the letters when using Gran Paradiso Alpha 1.

Reproducible: Always

Created an attachment (id=248671)
What a menu looks like under 3.0a1

If you compare this to 2.0, you can tell that the right pixel is cut off of each line of text. It is most obvious on the lowercase 's' on the bottom two options shown in that picture. The left pixel is also cut off of each line, but it is harder to tell. All of the text is clearly "dimmer" looking and not properly aliased for cleartype display, causing it to not look as sharp as it should and does under 2.0 and other browsers. Another small change noticeable is the space between the T and F on the second and third lines is 1 pixel less in 3.0a1 for some reason.

Created an attachment (id=248672)
What a menu looks like under 2.0

It seems that Cairo is unable to correctly detect the subpixel ordering of the screen, and does a BGR-ordered ClearType on the text. Or maybe a result of both Cairo and Windows attempting to antialias the text.

Confirming bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1.

Further investigation shown that Cairo selects the wrong contrast level when rendering the text. Setting contrast to 1.0 using ClearType fixes the issue (although text will likely to look weird in other places if that is set). Probably Cairo incorrectly reads the contrast values and takes them as if they were squared (e.g. a level of 1.4 is treated as 1.4^2, that's around 2.0, while 1.0 is processed as 1,0^2=1.0). Another thing I noticed is that if you hover over the menu items, the bug disappears, but opening a submenu causes it to re-appear. Testcase coming soon.

Created an attachment (id=248910)
Testcase

Testcase. Hover over the menu in it to trigger the bug.

It looks like the culprit is in cairo-win32-font.c, judging from these comments (line 1186):

"* Otherwise, we need to draw using software fallbacks. We create a mask
 * surface by drawing the the glyphs onto a DIB, black-on-white then
 * inverting. GDI outputs gamma-corrected images so inverted black-on-white
 * is very different from white-on-black. We favor the more common
 * case where the final output is dark-on-light."

After that (at line 1212):

"* For ClearType, we need a 4-channel mask. If we are compositing on
 * a surface with alpha, we need to compute the alpha channel of
 * the mask (we just copy the green channel). But for a destination
 * surface without alpha the alpha channel of the mask is ignored"
(Let's not forget that our surface is semi-transparent, so it does have an alpha!)

And a few lines later (line 1225):

"* XXX: Hacky, should expose this in cairo_image_surface"

Probably this is a bug in Cairo itself, but it seems to need quite a major rewrite.

*** Bug 355972 has been marked as a duplicate of this bug. ***

*** Bug 357456 has been marked as a duplicate of this bug. ***

Created an attachment (id=289559)
Screenshot

Firefox 3.0 does something differently with on-screen type. This leads to excessive color fringing in some cases. Please see the attached screenshot (which may not make any sense if you don't use an LCD screen). The upper text is from Firefox 2.0 and the lower is from 3.0b1

Is it different from other GTK/Pango apps on your system?

Created an attachment (id=289572)
Screenshot of native text

Screenshot is the same sentence typed into gedit with the same font, Droid Sans 12.

Ok, I'm not really sure what's going on here. Michael might be able to help out next week.

This may be related to the cairo version. I could see differences in rendering between cairo 1.4 (native GTK apps) and the more recent Firefox cairo. See bug 375591 comment 6

Created an attachment (id=308313)
screenshot from lineage2.com

On hover the bug is still visible. See the attachment. Why this bug is not blocker, when clear type technology is used mostly in LCD monitors, and its full of them now.

Yes, I can confirm this behaviour as well on Ubuntu Gutsy and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008022304 Minefield/3.0b4pre. The problem is exactly as described by the bug creator.

I can confirm the same problem on Fedora 9 and Manfield 3.0 beta 4.

*** Bug 375591 has been marked as a duplicate of this bug. ***

This is clearly a cairo issue. See:

https://bugs.freedesktop.org/show_bug.cgi?id=10301

Things are actually stalled upstream unfortunately. Ubuntu/Debian users are lucky because their cairo is patched against this bug.

Created an attachment (id=314121)
ClearType/Opacity bug in 3 Beta 5 - Inline HTML (No layers/DHTML)

Seems like this bug has gotten worse in 3 Beta 5... I'm using opacity to fade out adjacent month dates in our in-house web calendars, and in Beta 5 the '1' digits are suffering badly. This is all relatively positioned CSS, no floats, no z-indexing or layers. Problem goes away with ClearType turned off.

This bug also manifests itself in the chrome as well if the element or it's parent uses opacity or has rounded borders (-moz-border-radius) The Glasser extension screenshots show this problem alot:

http://www.neowin.net/forum/index.php?showtopic=632112

I absolutely consider the Glasser extension an essential now, but this bug is really bugging me quite a lot. I tried turning off ClearType, but the font looks absolutely hideous on a LCD monitor.

*** Bug 431904 has been marked as a duplicate of this bug. ***

The Glasser Extension does not work properly because of this ...

That's nothing new but there also many websites that just look crappy because of this. It's really sad that this doesn't get fixed for 3.0.

*** Bug 434666 has been marked as a duplicate of this bug. ***

Created an attachment (id=321706)
A sample HTML file showing css opacity usage with various color text and background

Created an attachment (id=321707)
opacity_test_p.html with cleartype enabled

Rendered in Firefox 3 RC1 on Windows Vista.

Created an attachment (id=321708)
opacity_test_p.html with cleartype disabled

Rendered in Firefox 3 RC1 on Windows Vista.

*** Bug 436760 has been marked as a duplicate of this bug. ***

*** Bug 370429 has been marked as a duplicate of this bug. ***

(In reply to comment #37)
Have you tried doing an rgb->hsl conversion and using one of those numbers? I don't really understand what's going on there (pardon the bug spam if I'm way off track), but just glancing at the patch, it seems like lightness might be a better match.

It doesn't just effect opacity. Check out http://www.mobify.me/ for a real world example. The "Learn More" text has an opacity set for .9999, but the upper right hand "Sign-up" doesn't. Changing color to other then white (via firebug) helps. To see it even better, turn off backgrounds with firebug.

Using Vista 64 with ClearType, FF 3.5.5 and FF 3.6 beta.

I noticed that the growl like new mail notification on Thunderbird 3.0b4 has the strangely colored anti aliasing too.

I was going to submit for a new bug, but this is exactly the same thing here. Xft and Cairo color fringing has been a long standing problem, and David Turner (you know, Mr. Freetype) wrote a patch addressing it loooong time ago. Somehow the Freedesktop.org people just wouldn't accept it, then again they don't always make the best decisions when it comes to font rendering. However, since Mozilla by default uses embedded libcairo, I really don't see any reason the patch can't be applied when building. Turner patches can be found on his site at freetype:

http://david.freetype.org/lcd/

which will not work for current versions of Cairo now, but there's the ubuntu patch derived from it:

http://archive.ubuntu.com/ubuntu/pool/main/c/cairo/cairo_1.8.6-1ubuntu2.diff.gz

I also have my own version adapted from Turner's original patch that applies cleanly against cairo 1.8.* -- which is the sole reason I build Firefox from source on my laptop. It would be great if Mozilla can just apply this patch when building release binaries, as it would save a lot of eyesore for users.

Ubuntu patches cairo and fontconfig to use the newer FreeType subpixel filters, whereas upstream cairo doesn't (yet). The whole thing is very controversial since those filters are suspected to infringe patents in the US...

So, that's where the discrepancy comes from...

This build (http://www.osnews.com/comments/22543) of "Firefox 3.7 with built-in Direct2D acceleration" seems to have fixed the issue (uses different font renderer?). I was suspecting some sort of hex math rounding issue, or using the full number instead of each channel's number separately.

Please see Bug 512136 (https://bugzilla.mozilla.org/show_bug.cgi?id=512136)
for windows possible related bug, with a test for windows vista/7 with cleartype https://bug363861.bugzilla.mozilla.org/attachment.cgi?id=321706

*** This bug has been marked as a duplicate of bug 363861 ***

*** Bug 512136 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> Please see Bug 512136 (https://bugzilla.mozilla.org/show_bug.cgi?id=512136)
> for windows possible related bug, with a test for windows vista/7 with
> cleartype https://bug363861.bugzilla.mozilla.org/attachment.cgi?id=321706

That's bug 363861, which isn't related to this one.

the new DirectWrite backend in Cairo, and demonstrated in this build (http://www.basschouten.com/media/blogs/blog/warning.html) fixes the issue for me (on Vista x64).

> ... The whole thing is very controversial
> since those filters are suspected to infringe patents in the US...

But the specific patch mentioned doesn't directly do anything about glyphs. It only enables lcdfilter options if it's _already compiled_ into the system's FreeType libs; that is, any patent issue would lie not in cairo, but in the freetype binaries because the distribution or the user chose to enable patented features, so it shouldn't be a problem for Mozilla source to include that patch. Am I misunderstanding the situation here?

Can you require a freetype new enough to have that API? (I think they were introduced in 2.3.0). Or doing dlopen tricks again?

> Can you require a freetype new enough to have that API? (I think they were
> introduced in 2.3.0). Or doing dlopen tricks again?

Turner's first lcd patch was for cairo-1.0.4, which was what, 3 years ago? The patch I use was originally for cairo-1.2.4, also ancient. I'd think the lib version is a non-issue here.

However, I think it is, if the base system is still RHEL5.

RHEL5 itself has Cairo > 1.2.4 already, why would it be a problem?

I'm talking about FreeType version. Cairo doesn't matter since Mozilla ships its own cairo.

I meant to say, if the cairo version is recent enough, freetype is probably ok--which was not true. I compiled freetype-2.2.1 (that's what RHEL5 has I think), and patched cairo fails when linking against it. Bummer.