Opened 8 years ago

Closed 2 years ago

#7797 closed bug (fixed)

[app_server] Alternative implementation of subpixel rendering (patch)

Reported by: diver Owned by: leavengood
Priority: normal Milestone: Unscheduled
Component: Servers/app_server Version: R1/Development
Keywords: Cc: stippi
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by diver)

Patch by Claudio Leite which turns on subpixel rendering:

Looks great on two my screens. Would be nice to have it integrated in Appearance preflet as well to easily switch between different types of rendering.

Attachments (3)

subpix_aa.diff (2.5 KB) - added by diver 8 years ago.
haiku-ftfil-hint.png (208.0 KB) - added by diver 8 years ago.
haiku-avgfil-hint.png (197.7 KB) - added by diver 8 years ago.
current freetype rendering

Download all attachments as: .zip

Change History (25)

Changed 8 years ago by diver

Attachment: subpix_aa.diff added

comment:1 Changed 8 years ago by diver

Has a Patch: set

Changed 8 years ago by diver

Attachment: haiku-ftfil-hint.png added

comment:2 Changed 8 years ago by diver

Cc: stippi added

Changed 8 years ago by diver

Attachment: haiku-avgfil-hint.png added

current freetype rendering

comment:3 Changed 8 years ago by tqh

That patch enables patented code by default and, in the discussion linked, Claudio states he will work on improved patches. It would probably be better to ask him on an update in that discussion and refer to this bug.

comment:4 Changed 8 years ago by tqh

I've asked for an update on the mailinglist.

comment:5 Changed 8 years ago by stippi

The patch as is cannot be applied, but I am all for giving the user more options, especially since text rendering is a touchy subject and depends on personal taste and preference a lot.

comment:6 Changed 8 years ago by diver

Description: modified (diff)

comment:7 Changed 7 years ago by tqh

Has a Patch: unset

comment:8 Changed 7 years ago by tqh

Marking patch obsolete on comment:5. This bug should probably be closed if nobody hears from Claudio.

comment:9 Changed 7 years ago by leavengood

It is a real shame Claudio hasn't come back because I really liked how the fonts looked in his screenshots. I wish he had even provided his "bad" patches so we could try making the nice version ourselves. Though if it is just a matter of turning on some features of FreeType it might be pretty easy.

Like Claudio I'm a real stickler for good font rendering and I think it would be nice if Haiku had more options. Personally the Ubuntu font rendering is one of my favorites.

I emailed Claudio personally and I'll see if he gets back to me.

comment:10 Changed 7 years ago by diver

Version: R1/alpha3R1/Development

comment:11 Changed 7 years ago by leavengood

Claudio emailed me back and provided the same patch as was originally posted here. Since some source files have moved since that patch was made I started making the same changes manually in order to test the changes and soon came to discover that freetype has been moved into an optional package as of hrev43869 from March 17, 2012.

In that optional package korli chose to disable the subpixel rendering, and since it is a compile time option, we cannot really provide it without compiling a specific freetype optional package with that option enabled. Though the beauty of that approach is it should be possible to provide that optional package and let people download it without making changes in Haiku. So people could use this subpixel rendering without having to compile Haiku themselves. And we could have some warning about "this is patented code, download at your own risk" or something to avoid patent issues.

Anyhow to conclude I'll try to make my own freetype with this option turned on and see how that works with this patch.

comment:12 Changed 7 years ago by leavengood

Owner: changed from axeld to leavengood
Status: newin-progress

To update this ticket, I was able to get nice subpixel rendering working by doing two things:

  1. adding this call from Claudio's patch to the app_server:

FT_Library_SetLcdFilter(fLibrary, FT_LCD_FILTER_DEFAULT);

  1. Turning on the subpixel rendering in the FreeType code, compiling it, and installing it.

Also I have learned that the above call will return an error if subpixel rendering support is not enabled in the current build of FreeType. So I plan to make use of that to set a variable in app_server indicating whether subpixel support is available. This can then be used in the Appearance preferences.

Honestly that is how this should have been implemented originally, instead of using a define.

Anyhow the main reason I have not finished it is also because of two things:

  1. I need to take the time to study the app_server code more and figure out the best way for applications to ask about subpixel rendering. Since this FreeType code is deep within the app_server I'm concerned it may be a bit tedious so I have procrastinated on doing it.
  1. For this to fully work for everyone in an easy way, we need to build FreeType optional packages with the subpixel support turned on, for both GCCs (and probably now x86-64) and advise people to install those if they want subpixel rendering. Based on how it looks I would expect many people to want it. Though this could still be risky in the US with the patent concerns.

Frankly I wish we would just install it in Haiku, and only remove it if we get threatened, because the font rendering (to my eyes at least) is just much, much, much better.

Since I've been working on this, I'll take ownership.

comment:13 Changed 6 years ago by diver


comment:14 Changed 6 years ago by leavengood

Funny diver, I was just discussing this ticket with Rene. Since I'm now working on Haiku again and am using Haiku itself for most of that, I am motivated to finish this bug as described above.

comment:15 Changed 6 years ago by diver

For anyone interested, the following two patches enable subpixel rendering:

diff -urN freetype-2.4.9/include/freetype/config/ftoption.h freetype-2.4.9-enable-subpixel-rendering/include/freetype/config/ftoption.h
--- freetype-2.4.9/include/freetype/config/ftoption.h	2011-07-20 04:46:15.035913728 +0000
+++ freetype-2.4.9-enable-subpixel-rendering/include/freetype/config/ftoption.h	2012-09-05 16:30:50.453509120 +0000
@@ -92,7 +92,7 @@
   /* This is done to allow FreeType clients to run unmodified, forcing     */
   /* them to display normal gray-level anti-aliased glyphs.                */
   /*                                                                       */
diff --git a/src/servers/app/font/FontEngine.cpp b/src/servers/app/font/FontEngine.cpp
index bb02895..977a332 100644
--- a/src/servers/app/font/FontEngine.cpp
+++ b/src/servers/app/font/FontEngine.cpp
@@ -588,6 +588,8 @@ FontEngine::FontEngine()
        fLastError = FT_Init_FreeType(&fLibrary);
        if (fLastError == 0)
                fLibraryInitialized = true;
+       FT_Library_SetLcdFilter(fLibrary, FT_LCD_FILTER_DEFAULT);

comment:16 Changed 6 years ago by diver

Some comments from stippi:

  • FreeType contains its own sub-pixel rendering. It can provide that in the glyph bitmaps you get. It has its own filter, too.
  • app_server initially implemented its own filter (the GSoC student), not using the Freetype filter, but needing the define so Freetype can provide 3x width glyph bitmaps without filtering.
  • Then I didn't like either the Freetype filter (as seen in Linux distros) nor the filter which the GSoC student implemnented. (Andre was his name?)
  • So I implemented another "average based" filter, which I thought was brilliant at the time.

What you may do now is have app_server do its own filtering, only to replace it later with the Freetype filtering. Or both filters run! I.e. first the Freetype filter, and then app_servers average based filter. Which means you get worse results then you could. Unless of course you drag the slider in Appearance preflet all the way to one side, turning the app_server filter effectively off, so you only get the Freetype internal filter's result.

comment:17 Changed 5 years ago by stippi

I think the poor text rendering also depends a lot on the specific font. Nobody complains much about the default DejaVu fonts, since those contain hinting bytecode which works well with the hinting mode that Haiku uses from Freetype. Other fonts don't contain it and often it results in no hinting being done at all, especially for OpenType fonts it seems. contains code which shows how to use the Freetype auto-hinter to do vertical hinting only, bypassing the need for any subpixel filtering define. I think it works nicely, although it looks better with sub-pixel rendering and filtering than with gray-scale rendering.

comment:18 Changed 4 years ago by pulkomandy


It's time to review this again...

The page about patents at Freetype homepage has some information:

So, the patent is only on the subpixel filter is patented:

using a different colour filter thus circumvents Microsoft's patent claims.

We have our own filter already, which works rather well and has the nice feature of having this slider to allow adjusting the color fringes. Since it is a custom filter, I don't see any reason to disable it when font hinting is enabled.

Now on the freetype compilation options. There are two of them.

  /*                                                                       */
  /* Define TT_CONFIG_OPTION_SUBPIXEL_HINTING if you want to compile       */
  /* EXPERIMENTAL subpixel hinting support into the TrueType driver.  This */
  /* replaces the native TrueType hinting mechanism when anything but      */
  /* FT_RENDER_MODE_MONO is requested.                                     */
  /*                                                                       */
  /* Enabling this causes the TrueType driver to ignore instructions under */
  /* certain conditions.  This is done in accordance with the guide here,  */
  /* with some minor differences:                                          */
  /*                                                                       */
  /* */
  /*                                                                       */
  /* By undefining this, you only compile the code necessary to hint       */
  /* TrueType glyphs with native TT hinting.                               */
  /*                                                                       */
  /*   This option requires TT_CONFIG_OPTION_BYTECODE_INTERPRETER to be    */
  /*   defined.                                                            */
  /*                                                                       */
  /*                                                                       */
  /* Uncomment the line below if you want to activate sub-pixel rendering  */
  /* (a.k.a. LCD rendering, or ClearType) in this build of the library.    */
  /*                                                                       */
  /* Note that this feature is covered by several Microsoft patents        */
  /* and should not be activated in any default build of the library.      */
  /*                                                                       */
  /* This macro has no impact on the FreeType API, only on its             */
  /* _implementation_.  For example, using FT_RENDER_MODE_LCD when calling */
  /* FT_Render_Glyph still generates a bitmap that is 3 times wider than   */
  /* the original size in case this macro isn't defined; however, each     */
  /* triplet of subpixels has R=G=B.                                       */
  /*                                                                       */
  /* This is done to allow FreeType clients to run unmodified, forcing     */
  /* them to display normal gray-level anti-aliased glyphs.                */
  /*                                                                       */

We are disabling both of these, but I think we should disable only the second one. This way, the API for subpixel hinting is available and does not lead an error, and app_server can enable it. Then we are able to only replace the freetype package if we want to enable the Microsoft patented algorithm.

comment:19 Changed 4 years ago by stippi

These findings are correct. However, the custom sub-pixel filter (average based) looks crappy for any fonts that are not strongly hinted. If a glyph is already strongly hinted, or designed to fit a pixel grid in the first place, then the freetype subpixel filtering will actually make it more blurry, since perfectly aligned stems are blurred by the filtering. For this reason, I came up with the average based filtering. The idea was to take the gray scale anti-aliased result, and mix it with the unfiltered sub-pixel result. This should lead to a result which is sharper than the gray-scale rendering alone, but does not have color fringes as bad as the pure sub-pixel result. The slider lets the user adjust the weighting between the two results. In practice, it can still have strongly colored pixels. It has no blurring problem, but the freetype filtering is overall more homogeneous in appearance. Many people (including myself in the meantime) prefer the freetype blurring.

Way back in time, I came across a site which claimed there is prior art to the sub-pixel rendering, and the ClearType patents should be invalid. They mentioned that Apple used the trick on some two-color displays way back, but I don't remember the details. Of course this may not affect the patents if they only concern the exact method of filtering versus the idea of sub-pixel rendering in itself.

In any case, it should be possible to do what you recommend in comment:18. All app_server needs from freetype is to render the glyph with 3x the width. This is achieved by passing the flag which is disabled by the define. But it could also be accomplished by simply setting a transform matrix. If you don't want to mess with app_server code to do that, enabling just one of the defines hopefully gets the results.

comment:20 Changed 4 years ago by pulkomandy

Milestone: R1Unscheduled

comment:21 Changed 3 years ago by diver

From freetype 2.6.4 release:

CHANGES BETWEEN 2.6.3 and 2.6.4


    - A new  subpixel hinting  mode has  been contributed  by Nikolaus
      Waxweiler, which is now the  default rendering mode for TrueType
      fonts.  It implements  (almost everything of) version  40 of the
      bytecode engine.

      The existing code  base in FreeType (the  `Infinality code') was
      stripped to the bare minimum  and all configurability removed in
      the  name  of speed  and  simplicity.   The configurability  was
      mainly aimed  at legacy  fonts like Arial,  Times New  Roman, or
      Courier.  [Legacy fonts are fonts  that modify vertical stems to
      achieve clean black-and-white bitmaps.]  The new mode focuses on
      applying a minimal set of rules to all fonts indiscriminately so
      that modern and web fonts  render well while legacy fonts render

      Activation  of the  subpixel hinting  support can  be controlled
      with   the   `TT_CONFIG_OPTION_SUBPIXEL_HINTING'   configuration
      option  at compile  time: If  set to  value 1,  you get  the old
      Infinality  mode  (which  was  never  the  default  due  to  its
      slowness).  Value 2 activates the new subpixel hinting mode, and
      value 3 activates both.  The default is value 2.

      At run time,  you can select the subpixel hinting  mode with the
      `interpreter-version'  property (provided  you have  compiled in
      the corresponding hinting mode); see `ftttdrv.h' for more.

comment:22 Changed 2 years ago by diver

Resolution: fixed
Status: in-progressclosed

Mostly fixed in hrev50713 with FreeType 2.7 update. For more see #12966.

Note: See TracTickets for help on using tickets.