[Devel] sub-pixel RGB rendering: do we need it? [Re: FT_Set_Hint_Flags() , etc.]

[Vadim Plessky]

On Thursday 12 September 2002 5:39 am, David Turner wrote:
[...]
|  Note however that there are two disadvantages to the new default hinting
| mode:
|
|  - it produces monochrome glyphs that are of slightly lower quality than
|     with FT_LOAD_TARGET_MONO. This is not dramatic and can be "solved" by
|     performing a very simple to libXft and/or the XFree86 FreeType font
| backend (which know precisely when to render monochrome bitmaps).
|
|     I don't use FT_LOAD_MONOCHROME to automatically switch to
| FT_LOAD_TARGET_MONO for several reasons, one of them is that a different
| hinting mode might create different metrics for the same glyph, and this
| might break certain assumptions made by programs..
|
|  - it doesn't work very well with sub-pixel rendering activated within
| XFree86 (because the "gray" parts create visible color fringes). There are
| two solutions to this problem however:
|
|       * simply disable it ! that's what I've done on my two home LCD
| desktops, and frankly don't miss it much anyway.
|

I have more general question: do we need sub-pixel RGB rendering at all?
David, I am quite curious to hear your opinion on this. 

Theoretically, it should provide better results comparing to monochrome 
rendering.
But anti-aliased grayscale rendering provides "better rendering results 
comparing to monochrome [rendering]", too.
Which one is better?
As for now, I think grayscale AA rendering has appx. the same visual 
perception as sub-pixel RGB rendering.

There is a practical method to measure "richness" of rendered image: to save 
image to the hard disk and check file size.
screenshots of AA-gray and sub-pixel RGB variants have appx. the same amount 
of bytes (saved in .png format), while number of colors is of course much 
higher in RGB variant.
At the same time, screenshot with AA text is about 3-5 bigger in size than 
non-AA s/s. So anti-aliased text is definitly contains more information than 
non-AA'ed text.

To address here "ClearType has it" issue.
Rendering of fonts in Windows is historically terrible.
It's still sticked at year 1990-91 level, when TrueType was introduced for the 
first time.
At hat time, hinted TrueType font was great advantage, and all Windows users 
were happy with it. Nowdays, when 24-bit displays are pretty common (about 
50% of all active desktops, I guess), 5-shades-of-gray rendring is jut out of 
date.
So, ClearType is definitly progress over Windows98 or Windows 2000 font 
rasterizer, or over ATM on Windows.

But, on the other hand, FreeType is already much, much better that rasterizer 
in Win98/Win2K (haven't tested MacOS X)
So, would we get something actively promoting/developing RGB rendering?
I am not so confident in it.

May be, we should better migrate AA grayscale renderer to 12bits, or even 
16bits of gray per pixel (instead of current 8bit), and experiment with this?
Are there any LCD panels, or CRT diaplys allowing more than 8bits per pixel?

I think in early 90's CornerStone had some displays capable of more than 8bits 
of gray.
Does someone know something about this?

In the mean time, I guess it's posible to do 12-bit or 16-bit rendering 
internally, and than scale results to 8-bit using some non-liner filtration 
method.
AFAIK all modern scanners do something similar - they scan at higher than 8bit 
resolution, do interpolation in hardware, and than provide back to 
application 8bit values (for R,G,B channels)
What do you think about this?

|       * another option is to wait for another simple change in libXft to
|         either use FT_LOAD_TARGET_MONO or FT_LOAD_TARGET_LCD/LCD_V to load
|         glyph outlines before rendering/filtering them..
|
|  My initial plan was to have FT_LOAD_TARGET_NORMAL perform like
|  FT_LOAD_TARGET_MONO by default (to get results similar to previous
|  releases of the library) and introduce a new FT_LOAD_TARGET_SMOOTH
|  mode.
|
|  However, this would have meant the following things:
|
|     - I'd need to hack libXft to be able to use the new render mode on
|       my desktops (I consider that eating your own dog food is important
|       in the case of hinting research :o) And no, thank you, I don't want
|       to do that right now...
|
|     - The "smooth" hinting would remain an option, instead of the default,
|       and you'd need a cooresponding new option in the libXft configuration
|       file, and consequently in the KDE / Gnome control panels to activate
| it.
|
[...]
|
|  Best Regards,
|
|  - David Turner
|  - The FreeType Project  (www.freetype.org)
|  _______________________________________________
|  Devel mailing list
|  address@hidden
|  http://www.freetype.org/mailman/listinfo/devel

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/