[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] sub-pixel RGB rendering: do we need it? [Re: FT_Set_Hint_Flags()
From: |
Vadim Plessky |
Subject: |
[Devel] sub-pixel RGB rendering: do we need it? [Re: FT_Set_Hint_Flags() , etc.] |
Date: |
Fri, 13 Sep 2002 12:38:09 +0400 |
User-agent: |
KMail/1.4.6 |
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/
- [Devel] FT_Set_Hint_Flags() , etc., David Chester, 2002/09/09
- [Devel] Bug caused by strange unicode character name., George Williams, 2002/09/10
- Re: [Devel] FT_Set_Hint_Flags() , etc., David Turner, 2002/09/11
- Re: [Devel] FT_Set_Hint_Flags() , etc., Artur Zaprzala, 2002/09/12
- [Devel] sub-pixel RGB rendering: do we need it? [Re: FT_Set_Hint_Flags() , etc.],
Vadim Plessky <=
- Re: [Devel] FT_Set_Hint_Flags() , etc., Vadim Plessky, 2002/09/13
- Re: [Devel] FT_Set_Hint_Flags() , etc., Werner LEMBERG, 2002/09/17
- Re: [Devel] FT_Set_Hint_Flags() , etc., Werner LEMBERG, 2002/09/17
- Re: [Devel] FT_Set_Hint_Flags() , etc., Vadim Plessky, 2002/09/12