[cairo] Discussion: LCD Filtering API

[Behdad Esfahbod]

Hi Lance,

The filtering should go into a file of its own for now.  "cairo-lcd-filter.c"
works for me.  The public API will look like what was committed and reverted.
 The main function in that file will take a cairo image surface and a
filtering mode and subpixel order, and returns a new surface that has the
filtering results...

The rest of the work will be done in cairo-scaled-font.c.  Note that I need to
do some code reshuffling before this can be hooked up.

Thanks,
behdad

Lance Hepler wrote:
> Hi Owen,
> 
> It seems that Behdad is not interested in disturbing the ability to do
> native-style rendering. He's interested in making it possible to do
> rasterization in cairo so that animation of text can be done well. This
> is an excellent point.
> 
> I don't see any issues in that at all. The question is, how/where do I
> want to put a new file/funtions that contains the lcd filtering code
> that I've ripped from freetype? And how do we want this API to look,
> even if we keep it private for cairo until we're happy with it?
> 
> I'm perfectly fine ripping out the sections of freetype that do the
> filtering (I'm sorry D. Turner!), making another file (seems best, since
> we want this filtering available for all backends, not just freetype)
> for doing lcd filtering in the cairo src directory, and hooking the
> calls in cairo-ft-font.c to use this code to filter instead of Freetype.
> Looking over ftlcdfil.c it doesn't seem to be too difficult to adjust
> the code to work within a cairo-only context. As long as we keep pulling
> in the preferences from fontconfig, there shouldn't be any regressions,
> and I don't foresee tremendous difficulty in making this adjustment. Of
> course, I haven't looked at the formats we're using to keep the other
> backends bitmapped glyphs, so maybe I'm just naive.
> 
> Anyways, doing this now will give us the immediate benefit of having
> these improved filtering methods finally upstream, which would be of
> benefit to the unnamed distros that are currently using one version of
> the 10301 patch or another. That, and I'm sure users of those distros
> that are not using the 10301 patches will benefit from/be grateful for
> the improved font rendering. Really, I just want to go the route that
> will upstream these filtering abilities as soon as possible. 
> 
> I am really interested and anxious to see the putative improvements in
> font rendering Behdad has planned (subpixel positioning for
> unhinted/slightly-hinted fonts might be really nice! (they aren't really
> affected by the lsb/rsb deltas)).
> 
> Nicolaus (Lance)
> 
> On Thu, Jan 29, 2009 at 11:48 AM, Owen Taylor <otaylor at redhat.com
> <mailto:otaylor at redhat.com>> wrote:
> 
>     On Thu, 2009-01-29 at 01:39 -0500, Behdad Esfahbod wrote:
>     > Hi Lance,
>     >
>     > I agree with most of your positions.  However, my long term plan
>     is to move
>     > glyph rasterization away from FreeType and into cairo, and that
>     includes
>     > subpixel rendering.  I think the API should wait till that
>     happens.  In that
>     > case Carl's remaining issues will be moot as we can do the same
>     filtering on
>     > all platforms and it will not be FreeType-specific anymore.
> 
>     One thing to be concerned about is that matching the system rendering.
>     Whether text looks good is not just a matter of whether it looks good in
>     isolation, but whether it matches other text on the screen in contrast
>     and other characteristics.
> 
>     For example, if you take some text rendered on the Mac, and drop it onto
>     a Windows desktop, the typical reaction will be that it is fuzzy. Taking
>     text the other way may produce complaints about letter shapes or color
>     fringing.
> 
>     - Owen
> 
> 
>