[app_server] Alternative implementation of subpixel rendering (patch)

[diver]

Patch by Claudio Leite which turns on subpixel rendering:
​http://www.freelists.org/post/haiku-development/Alternative-implementation-of-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.

[diver]

current freetype rendering

[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.

[tqh]

I've asked for an update on the mailinglist.

[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.

[tqh]

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

[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.

[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.

[leavengood]

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);

2. 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.

2. 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.

[diver]

ping.

[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.

[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.                */
   /*                                                                       */
-/* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
+#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
 
 
   /*************************************************************************/

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);
 }

[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.

[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.

​http://www.antigrain.com/research/font_rasterization/index.html 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.

[pulkomandy]

Hi,

It's time to review this again...

The page about patents at Freetype homepage has some information: ​http://freetype.sourceforge.net/patents.html

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:                                          */
  /*                                                                       */
  /*  http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx */
  /*                                                                       */
  /* 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.                                                            */
  /*                                                                       */
/* #define TT_CONFIG_OPTION_SUBPIXEL_HINTING */

  /*************************************************************************/
  /*                                                                       */
  /* 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.                */
  /*                                                                       */
/* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */

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.

[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.

[diver]

From ​freetype 2.6.4 release:

CHANGES BETWEEN 2.6.3 and 2.6.4

  I. IMPORTANT CHANGES

    - 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
      okay.

      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.

[diver]

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

[leavengood]

Two things have changed in FreeType since most of the discussions in this ticket:

1. The new subpixel hinting changes Diver shows above.
2. And a new subpixel rendering mode, which is now on by default.

I could be wrong, but I do not think the Haiku font rendering code is properly taking these into account anymore.

Many Linux distros had their font rendering screwed up by these FreeType changes. I think the FreeType people made a mistake in making these changes the default.

I think it warrants more looking again. I will see what I can learn but I think jua and stippi are in a better position to judge was might need to be fixed. See my recent mailing list post: ​https://www.freelists.org/post/haiku-development/Haiku-Font-Rendering

Of course maybe something is messed up with my configuration. I have not run Haiku on real hardware in a long time. Maybe the font rendering looks fine in that case, though I don't see why it would be any different than my VM. You can see a screenshot in the above mailing list post.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone