BGR-ordered subpixel font rendering appears broken/nonfunctional in Gnome/GTK+

[Clarke Wixon]

I'm filing this bug against gtk+, but frankly I don't know exactly what package is the culprit. It's occurring somewhere between the Gnome "Appearance" preference panel and freetype, I suppose.

In summary, subpixel-antialiased font rendering to a Blue-Green-Red (BGR) ordered display panel is broken in Maverick (10.10, Gnome). There is NO DIFFERENCE between text rendered using the "RGB" setting and the "BGR" setting. It is blurry and fringy on my BGR panel in both cases, contrary to my experiences over the last few years with previous releases, under which I always had sharp results.

I'm running Ubuntu 10.10, 64-bit, on a generic PC with an Nvidia 7900GS card, using the latest proprietary Nvidia driver. The monitor is a Dell 1800FP, one of the few BGR panels out there, unfortunately, and it is connected via DVI.

There is no change whatsoever when toggling between the two horizontal subpixel options in the "Appearance" settings panel (System->Preferences->Appearance->Fonts->Details). No matter how closely I look, not a single pixel changes. I can see small changes (as expected) when I go back and forth between "RGB" and "VRGB," for example, but "RGB"<->"BGR" appears to do absolutely nothing.

I can verify that what I'm seeing (with either "RGB" or "BGR" selected) is, in fact, RGB-ordered subpixel rendering. If I take a screenshot and mirror it horizontally, which essentially turns RGB into BGR, what I see is very nice, clear text on my screen. Unmirrored, it's ugly and fringy.

I have tried various versions of the Nvidia driver, and it doesn't help. Nor does using an unaccelerated driver. Nor does the status of compiz desktop effects, on vs. off.

I have had excellent font rendering in the past, up through and including Lucid (10.04).

In Firefox, for some reason, the systemwide RGB/BGR setting *does* work. If I select "BGR" in the Gnome appearance preferences and refresh a web page, it looks GREAT! Re-select "RGB," refresh, and it's ugly again. All other text on the screen in Gnome/GTK applications remains unchanged.

And Qt-based applications also work correctly, according to the settings I have in ~/.fonts.conf. Those applications have great-looking text.

So there's something weird going on. This preference isn't being respected by my desktop or the Gnome/GTK applications I use, and it has worked perfectly in the past. My Google searches for others experiencing this problem have come up empty.

In attempting to troubleshoot this problem, I tried numerous different LiveCD images to see whether they worked. (I booted them in a kvm virtual machine, and carefully inspected their on-screen output.) Here's the summary:

Ubuntu 10.10: BROKEN - no BGR font rendering (both 32-bit and 64-bit versions tested)

Xubuntu 10.10: BROKEN - no BGR font rendering

Ubuntu 11.04 alpha: BROKEN - no BGR font rendering

Ubuntu 10.04.1: WORKS FINE!

Kubuntu 10.10: WORKS FINE!

Obviously, in each case, I had to change the default rendering options through settings.

So apparently BGR font rendering is OK in KDE/Qt, and broken in GTK-based releases, both Gnome and XFCE. And the bug seems to be carrying over into Natty, at least early in its cycle.

I look forward to seeing this regression corrected.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libgtk2.0-0 2.22.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-24.42-generic 2.6.35.8
Uname: Linux 2.6.35-24-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Fri Jan 14 22:14:58 2011
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gtk+2.0

[Clarke Wixon (cwixon)]

I'm a little dismayed at the lack of action here, because Natty Alpha 2 just came out, and I verified it has exactly the same problem (following booting from the AMD64 LiveCD).

I have objectively verified my findings. There is NO DIFFERENCE between RGB-ordered font rendering and BGR-ordered font rendering in Gnome/GTK+ applications, where there absolutely should be.

I opened up a galculator window (selected because it is a static window with a variety of fine text and no blinking cursor or other distractions). With the program open and otherwise unused, I selected each of the four possible subpixel antialiasing options (RGB, BGR, VRGB, VBGR) via the Gnome appearance settings panel, in turn, and each time I captured a screenshot of just the galculator window.

I then calculated md5sums on each of the resulting PNG files.

7e9d1be5a35fb8c9e02f5744db81d765 Screenshot-galculator-bgr.png
7e9d1be5a35fb8c9e02f5744db81d765 Screenshot-galculator-rgb.png
778b69aa3eb0dee4aa6faca84eb6ee15 Screenshot-galculator-vbgr.png
f6d55d5d5fcdd6d43ad9e12547138aa0 Screenshot-galculator-vrgb.png

As you will see, the -bgr and -rgb screenshots calculate to exactly the same md5sum. THERE IS NOT A SINGLE PIXEL DIFFERENCE.

In contrast, -rgb, -vrgb, and -vbgr are all different, as expected.

Would someone mind confirming this bug? I'd like to get it fixed. Font rendering is one of the reasons I moved away from Windows more than five years ago.

I'm attaching 4x enlargements of a crop of each of the galculator window screenshots. If you look at the color fringing around the word "log," you should be able to see what I'm talking about. Between -vbgr and -vrgb, the red and blue fringes around the "o" and "g" switch between top and bottom, as expected. But with both -rgb and -bgr, the red fringes stay on the left and the blue fringes stay on the right in both cases, when they should be switching.

I don't know how much more I can say about this, so I'll leave it there and hope for some further input from a developer or maintainer.

[Ingo Ruhnke (grumbel)]

Same issue here, RGB and BGR give identical results, instead of the different ones like VBGR and VRGB. Attached are a few screenshots that clearly shows the issues.

In case it matters: I am using a multi-monitor setup with two monitors that have different subpixel ordering, so results will be blurry on one monitor either way, but that shouldn't stop Gtk or whatever is at fault, to respect the given setting.

[Sebastien Bacher (seb128)]

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[Ingo Ruhnke (grumbel)]

Another observation: Switching to grayscale smoothing does not actually enable grayscale smoothing, the actual font rendering continues to be LCD(subpixel) smoothing, it now will however also ignore BGR, VBGR and VRGB settings and do RGB the whole time.

[Clarke Wixon (cwixon)]

Thanks for the additional observation, Ingo, and also for confirming my original report (despite the fact that resolving this bug won't really help you one way or the other, given your two-monitor situation).

I tested the recently released Natty Alpha 3 Live CD, and it too shows this same problem.

I will take a shot at reporting this on the Gnome bugzilla; I have an account over there already. I probably won't get a chance to do it until later this weekend, but I did perform a search, and didn't find these symptoms in any other bug report.

[Jens Reimann (ctron)]

I have the same problem with natty (11.04). I upgraded from 10.04 where the default setting RGB worked fine an came out (after a clean install) with RGB and BGR providing the same, shifted, output. So I would assume that instead of RGB (which is selected) BGR is always used for rendering since RGB worked fine for me before that.

I tried with:

ATI Technologies Inc Redwood PRO [Radeon HD 5500 Series]: Closed and open source drivers
nVidia Corporation G94 [GeForce 9600 GT] (rev a1): Closed and open source drivers

all on natty 11.04 (release).

The changes of hardware or drivers does not seem to make a difference.

Monitors are: Philips 220WS using DVI and H-W22S using VGA

[Simon Elmir (nerd65536)]

I can confirm the same behavior on an HP TouchPad, Ubuntu 11.04 armel port (armv7l). I'm running LXDE, and only gtk apps are affected. Firefox renders fonts correctly, and so do the KDE apps.

[Simon Elmir (nerd65536)]

I posted a bug report on Gnome's tracker.

[Ingo Ruhnke (grumbel)]

I dug around a bit, tracing where the subpixel value goes and it seems the problem is within Cairo or at least the subpixel_order value arrives safe and sound in the cairo_font_options_set_subpixel_order() call after going through gconf, xsettings and then back into Gtk. No idea yet what goes wrong after that.

[Ingo Ruhnke (grumbel)]

Did another test to confirm that the problem is in cairo. The attached program will generate a /tmp/out.png with text in RGB, BGR, VRGB and VBGR ordering, the vertical ordering will show up correctly, while the horizontal ones are identical. Furthermore on option of the type:

    cairo_font_options_set_antialias(fopts, CAIRO_ANTIALIAS_GRAY);

will still produce subpixel anti-aliasing, not grayscale, i.e. all the same problems that can be seen in the Ubunte Font Rendering Details dialog.

[Ingo Ruhnke (grumbel)]

Found the cause of all the trouble, a missing "break;" in Cairo in src/cairo-ft-font.c, it's present in upstream as well it seems and not Ubuntu specific. Patch attached.

[Ingo Ruhnke (grumbel)]

Looks to be only a partial fix, grayscale anti-aliasing still produces subpixel anti-aliasing.

[Ingo Ruhnke (grumbel)]

Filled two bug reports, along with patches, against upstream Cairo:

BGR issue: https://bugs.freedesktop.org/show_bug.cgi?id=40456
Gray issue: https://bugs.freedesktop.org/show_bug.cgi?id=40458

[Nerd65536+bugzilla (nerd65536+bugzilla)]

If you configure the system to use BGR subpixel font rendering, Firefox 7 and later incorrectly use RGB subpixel font rendering instead. See attached illustrations

A patch is available on the Cairo bug for this issue: https://bugs.freedesktop.org/show_bug.cgi?id=40456

[Nerd65536+bugzilla (nerd65536+bugzilla)]

Created attachment 564451
Correct rendering in Firefox 6.0.2

[Nerd65536+bugzilla (nerd65536+bugzilla)]

Created attachment 564452
Incorrect rendering in Firefox 7.0.1

[Nerd65536+bugzilla (nerd65536+bugzilla)]

Created attachment 564453
Incorrect rendering in Firefox 10.0a1 Nightly: 2011-10-03

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Fixes missing break in switch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Sebastien Bacher (seb128)]

http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-2&id=7967b6eb4ec78f5553a02eb97236ef3b91d80998

[Sebastien Bacher (seb128)]

the issue in g-s-d got fixed in the Oneiric version, there is now a cairo patch waiting for review in bugzilla.fd.o

[Clarke Wixon (cwixon)]

Confirmed in Firefox 7.0.1 here -- I'm the original reporter on Ubuntu bug 703191 (listed under "See Also"), and I have manually patched Cairo on my own system using Ingo Ruhnke's patch (attached to freedesktop.org bug 40456). This solves the problem system-wide EXCEPT in Firefox.

[Clarke Wixon (cwixon)]

The cairo patch in freedesktop.org solved the problem for me.

I manually applied the patch in cairo 1.10.2, built it and manually installed it over the packaged version in Natty.

BGR-ordered subpixel font rendering now looks fine systemwide, and switching back and forth between RGB and BGR has the expected effect.

[Clarke Wixon (cwixon)]

Perhaps unsurprisingly, this bug can be fixed by making the same patch that fixes the system-level cairo library.

I manually patched firefox 8.0b3 to test. The patch goes into the cairo version that's embedded in the firefox source, at [RELEASE]/gfx/cairo/cairo/cairo/src/cairo-ft-font.c.

[Clarke Wixon (cwixon)]

This is a longstanding, obvious, easily verifiable bug with a trivial fix, as cited above.

It's still present in FF10 final. Can we get this implemented PLEASE?

I have to manually patch and compile each Firefox release. I'm sure others would benefit from having the fix integrated into the source.

[Note that in my comment of 2011-10-16, I have the directory not quite correct -- too many nested "cairo"s. It's actually [RELEASE]/gfx/cairo/cairo/src/cairo-ft-font.c]

[Ajuma (ajuma)]

Created attachment 594570
The patch from upstream

This is the patch from https://bugs.freedesktop.org/attachment.cgi?id=50673, which adds a missing break statement.

[Clarke Wixon (cwixon)]

The rendering bugfix is incorporated into cairo 1.11.4, released 2012-03-12, so that's a little bit of progress I suppose.

For whatever reason, though, now that I'm running Ubuntu 12.04 beta, even my lovingly hand-patched and compiled version of Cairo doesn't seem to resolve this problem anymore. (It worked in 11.04 and I skipped 11.10.)

And I also see that the UI for selecting a desired subpixel orientation has been removed from Ubuntu (though there's still a key in gconf at /desktop/gnome/font_rendering/rgba_order).

Argh.

You know what DOES work? Mounting my monitor upside-down. Voilà, instant R-G-B stripe order.

That's what it has come to.

[Clarke Wixon (cwixon)]

Can we get this fixed please? It is a real eyesore to those of us with B-G-R striped monitors.

It's a one-line patch: a simple "break" statement missing in the Cairo font renderer. The Cairo patch has been available for well over a year, and it has been fixed in Cairo releases since 1.11.4 (2012-03-12).

I patched the FF 16.0.2 source manually and I can confirm -- as I did over a year ago when I patched FF 8.0b3 -- that the patch works.

[Jmuizelaar (jmuizelaar)]

Comment on attachment 594570
The patch from upstream

Sorry this took forever

[Ryanvm (ryanvm)]

Doesn't this require accompanying changes to the README, a patch checkin, etc?

[Joe-drew (joe-drew)]

Jeff says not to bother, since this is actually stealing a patch from upstream.

[Ryanvm (ryanvm)]

OK. I await the mythical upstream update we'll eventually take to make everything right in the world ;)
https://hg.mozilla.org/integration/mozilla-inbound/rev/d0955470ac64

[Clarke Wixon (cwixon)]

While we await that mythical update I'll gladly take this one. Many thanks.

I'll test this when it filters down into a build, but as noted upthread, applying this patch and compiling locally works just fine.

[Ryanvm (ryanvm)]

https://hg.mozilla.org/mozilla-central/rev/d0955470ac64

[Clarke Wixon (cwixon)]

Tested in Firefox 22 - works great. Thanks.