Bug 29151

Summary: Subpixel LCD text rendering improvements
Product: xorg Reporter: Tom Callaway <tcallawa>
Component: Lib/XftAssignee: Jeremy Huddleston Sequoia <jeremyhu>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: jeremyhu
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard: 2011BRB_Reviewed
i915 platform: i915 features:
Attachments:
Description Flags
Add support for using freetype to handle subpixel LCD text rendering
none
Patch01 of 02 - Subpixel LCD text rendering improvements
none
Patch 02 of 02 Compiler noise cleanups related to subpixel LCD changes none

Description Tom Callaway 2010-07-19 11:10:41 UTC 
Created attachment 37182 [details] [review]
Add support for using freetype to handle subpixel LCD text rendering

David Turner, the upstream freetype author, has written a patch for
libXft to use the freetype subpixel text rendering hooks in the API. In copies of freetype which do not have the subpixel text rendering code enabled, these calls are effectively NOOP, they do not render any differently.

Attached is the patch that I applied (after a bit of cleanup) to
Fedora's rawhide libXft and tested. Because Fedora's freetype doesn't do
any real subpixel text rendering, there is no difference between the
session with libXft patched vs unpatched.

For proof, I offer screenshots of xterm -fa Monospace:

http://spot.fedorapeople.org/libXft-lcd-patch/BEFORE-xterm-fa-Monospace.png
http://spot.fedorapeople.org/libXft-lcd-patch/AFTER-xterm-fa-Monospace.png

The core benefit of this patch is that:

* Users who have the legal option of running freetype with enabled
subpixel text rendering will see that functionality enabled across
libXft and cairo.
* When those patents expire (or are declared invalid), libXft 
will not require any changes to leverage a freetype with enabled
subpixel text rendering.

As an additional note: this patch has been applied to Debian's copy of libXft for some time now.
Comment 1 Julien Cristau 2010-07-19 11:22:06 UTC 
On Mon, Jul 19, 2010 at 11:10:41 -0700, bugzilla-daemon@freedesktop.org wrote:

> As an additional note: this patch has been applied to Debian's copy of libXft
> for some time now.
> 
Maybe you mean Ubuntu's?  I don't think we're patching libXft, whereas
the patch seems to be in
http://patches.ubuntu.com/x/xft/xft_2.1.14-2ubuntu1.patch
Comment 2 Tom Callaway 2010-07-19 11:26:33 UTC 
Hmm, you're right. I could have sworn I saw it in the Debian patchset, as I don't normally even bother digging in Ubuntu packages for patchsets.

My apologies! The rest of the bug ticket still holds, though. :)
Comment 3 Jeremy Huddleston Sequoia 2011-10-06 11:24:54 UTC 
The patch unfortunately does not apply any more, and the current one in the 
downstream http://patches.ubuntu.com/x/xft/xft_2.2.0-3ubuntu1.patch also does 
not apply to current git.

If you were to update the patch to current git, I would be happy to review it 
and wrangle it in to a release.
Comment 4 Tom Callaway 2011-10-06 11:46:18 UTC 
Okay, I'll take a shot at it.
Comment 5 Tom Callaway 2011-10-06 13:01:23 UTC 
Created attachment 52055 [details] [review]
Patch01 of 02 - Subpixel LCD text rendering improvements
Comment 6 Tom Callaway 2011-10-06 13:01:55 UTC 
Created attachment 52056 [details] [review]
Patch 02 of 02 Compiler noise cleanups related to subpixel LCD changes
Comment 7 Tom Callaway 2011-10-06 13:02:21 UTC 
Here are patches against git as of an hour ago.
Comment 8 Jeremy Huddleston Sequoia 2011-10-06 14:59:45 UTC 
Thanks.  I'll review and test later this week.
Comment 9 Jeremy Huddleston Sequoia 2011-10-10 14:03:00 UTC 
FC_LCD_FILTER was added in 2008 and is in 2.5.92.  It seems better to me that 
we rely on a version of fontconfig with FC_LCD_FILTER.  I pushed your changes 
along with a followup to remove ifdef-fu:

To ssh://git.freedesktop.org/git/xorg/lib/libXft
   0e0efb8..550b2f7  master -> master

Thanks

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.