Closed Bug 404637 Opened 17 years ago Closed 13 years ago

Excessive color fringing in default builds vs. --enable-system-cairo builds on Ubuntu

Categories

(Core :: Graphics, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jwbaker, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: regression, Whiteboard: [fixed in Bug 562746 and Bug 660448])

Attachments

(2 files)

Attached image 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
Component: General → GFX: Thebes
Keywords: regression
Product: Firefox → Core
QA Contact: general → thebes
Is it different from other GTK/Pango apps on your system?
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
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.
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.
Depends on: 456448
Blocks: 400265
Changing summary to reflect the current manifestation of this bug.
Summary: Excessive color fringing in 3.0b1 (gecko 1.9b1) vs. 2.0 → Excessive color fringing in default builds vs. --enable-system-cairo builds on Ubuntu
Trying to build SeaMonkey on a ubuntu 9.04 machine. It builds fine when --enable-system-cairo is not set. When setted it does not build.

What cairo libs are needed?
Look for the CAIRO_VERSION variable in the configure.in file at the top of the source tree. For mozilla-central, that's Cairo 1.6 (http://mxr.mozilla.org/mozilla-central/source/configure.in#122).

If you have building issues, I suggest you comment in the mozilla.dev.builds newsgroup (http://groups.google.com/group/mozilla.dev.builds/topics for the Web interface). You should also provide the complete error message there.
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...
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
(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 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.
I think this should be fixed now, as of Bug 660448 landing, though most of the fix was in Bug 562746.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [fixed in Bug 562746 and Bug 660448]
Depends on: 562746, 660448
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: