[ft] Alternate subpixel antialiasing methods needed

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

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 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. It is crucial to get this feature implemented ASAP 
before someone else patented it. :)


[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