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 _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
