Re: [ft] Alternate subpixel antialiasing methods needed

[Werner LEMBERG]

Hello Quanta!


> Currently there are very few anti-aliasing methods available in
> current FreeType engine.  For sub-pixel anti-aliasing, the choices
> available (at least via FT_Render_Mode and FT_PIXEL_MODE) don't
> reflect the diverse range of available sub-pixel patterns on
> production displays.

At the time this has been written (almost ten years ago), it was state
of the art.  Meanwhile, David Turner, then our main developer, has no
longer time to work on such issues.

> FT2 currently seems to assume that modern LCD screens only does RGB
> pattern tiled in regular fashion, but fail to take into account for
> alternate sub-pixel tiling methods (eg: XO-1[1]), more than 3 colour
> channels per pixel (eg: Sharp Quattron[2]) or more than 3 sub-pixels
> per pixel (eg: large TVs made in 2010 or later[3]), sub-pixels that
> don't fit entirely within a rectangular pixel grid (eg: CRTs), or
> non-square sub-pixels (eg:
> Clairvoyante/Nouvoyance/SamsungPenTile[4]).
>
> [1] http://en.wikipedia.org/wiki/OLPC_XO-1
> [2] http://en.wikipedia.org/wiki/Quattron
> [3] http://www.avsforum.com/avs-vb/archive/index.php/t-1280303.html
> [4] http://en.wikipedia.org/wiki/PenTile_matrix_family

This is correct.

> In order to accommodate these alternative formats, FreeType will
> need to incorporate generic multisampling methods, similar to
> anti-aliasing done in rendering 3D scenes.  Except in the case of
> FreeType, the colour spaces and balances of sub-pixels need to be
> taken into account.  With multisampling, it also opens up the
> possibility to perform the anti-aliasing in video cards.

Before doing this, I think someone should modularize the already
existing modes, providing an (internal?) interface so that plugging-in
of recent colour patterns is simple.

> However, multisampling points to another bottleneck in FT2.
> Currently render mode and pixel mode features explicitly state the
> colour depths of the render target and rasterized glyphs
> respectively.  This may be fine for software rendering, but for
> anti-aliasing to be moved into hardware, it would be simpler to
> rework the anti-aliasing routines to just use whatever
> intermediate/final colour depths provided by the video card's
> hardware/current screen mode by default.  That will require the
> ability to inspect render and output hardware's capabilities.
> Furthermore, FT_Render_Mode and FT_PIXEL_MODE need to be redesigned
> so that colour depth, colour space, and sub-pixel geometry can be
> set independently.  The sub-pixel profiles of a given display will
> be loaded at run-time in separate instead of being compiled into
> FreeType, so future sub-pixel patterns can be supported using
> generic algorithms that optimizes anti-aliased output based on
> externally-supplied geometric and colour data without recompiling
> FreeType.

It sounds as if you know what you are talking about :-) I fully agree
with your analysis, however, I am not an expert in this field, and my
skills in this area are very limited, alas.

> It has the side benefit of supporting ClearType without explicitly
> supporting ClearType, since the combination of sub-pixel and colour
> data will not be known by FreeType until user chooses it.

Just for the record: `ClearType' can mean two things:

  . The patented colour filter for LCD rendering, which is easy to
    circumvent by using a different colour filter.

  . The special handling of some TrueType bytecode instructions if the
    target is a sub-pixel display.  This isn't patented, so no
    problems here.  Note, however, that it probably works well with
    `patterns in regular fashion' only (as you call it).

What you want is generic sub-pixel support for arbitrary colour
patterns, right?

> It is crucial to get this feature implemented ASAP before someone
> else patented it. :)

:-) Can you provide step-by-step patches for FreeType?


    Werner