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

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: Jeffrey Baker, Unassigned)

Tracking

(Depends on: 1 bug, {regression})

Trunk
x86
Linux
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Created attachment 289559 [details]
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

Updated

10 years ago
Component: General → GFX: Thebes
Keywords: regression
Product: Firefox → Core
QA Contact: general → thebes
Is it different from other GTK/Pango apps on your system?
(Reporter)

Comment 2

10 years ago
Created attachment 289572 [details]
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.

Comment 4

10 years ago
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

Comment 5

9 years ago
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.

Comment 6

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

Updated

9 years ago
Duplicate of this bug: 375591

Comment 8

9 years ago
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.

Updated

9 years ago
Duplicate of this bug: 436760
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?

Comment 12

8 years ago
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.

Comment 13

8 years ago
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.

Comment 14

8 years ago
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...

Comment 15

8 years ago
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

Comment 16

8 years ago
(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.

Comment 17

8 years ago
> ... 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?

Comment 18

8 years ago
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?

Comment 19

8 years ago
> 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.

Comment 20

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

Comment 21

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

Comment 22

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

Comment 23

8 years ago
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.

Updated

8 years ago

Updated

7 years ago
Duplicate of this bug: 541319

Updated

7 years ago
Duplicate of this bug: 581715
Duplicate of this bug: 590864
Duplicate of this bug: 541319
I think this should be fixed now, as of Bug 660448 landing, though most of the fix was in Bug 562746.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed in Bug 562746 and Bug 660448]
Depends on: 562746, 660448

Updated

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