[cairo] Discussion: LCD Filtering API

Behdad Esfahbod behdad at behdad.org
Wed Feb 4 11:09:13 PST 2009


Thanks Lance, this looks quite useful!  Please let me know if you update the
patch.

behdad

Lance Hepler wrote:
> Hi Behdad,
> 
> Attached is a patch that does what you suggest, with a few differences.
> It's an initial stab, but it works as expected.
> 
> Included in this patch are some changes to cairo-ft-font.c that hooks
> into this private function.
> I know that's not what you want, since you wanted to hook it into
> scaled-font, but I used this as a way to test it immediately.
> 
> Please review, comment, criticize. I learned a lot writing this patch.
> 
> Lance
> 
> On Mon, Feb 2, 2009 at 3:15 AM, Behdad Esfahbod <behdad at behdad.org
> <mailto:behdad at behdad.org>> wrote:
> 
>     Yeah, ARGB32 in the input doesn't make sense.  Now lets stop
>     designing and
>     writing code over email. :)
> 
>     behdad
> 
>     Lance Hepler wrote:
>     > Hi Behdad,
>     >
>     > Haha! Good thing. I've already started working on it. And that's about
>     > the way I've set it up.
>     > One question I have is whether I'll need to handle ARGB32 surfaces, as
>     > the current code simply handles 3x (width/height) CAIRO_FORMAT_A8
>     > surfaces. Should I just assume we'll only need it for the A8 case and
>     > assert so in the function? Expanding the code to filter ARGB32
>     surfaces
>     > would be ... tricky.
>     >
>     > Lance
>     >
>     > On Sat, Jan 31, 2009 at 10:35 PM, Behdad Esfahbod
>     <behdad at behdad.org <mailto:behdad at behdad.org>
>     > <mailto:behdad at behdad.org <mailto:behdad at behdad.org>>> wrote:
>     >
>     >     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>
>     >     <mailto:otaylor at redhat.com <mailto:otaylor at redhat.com>>
>     >     > <mailto:otaylor at redhat.com <mailto:otaylor at redhat.com>
>     <mailto: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
>     >     >
>     >     >
>     >     >
>     >
>     >
> 
> 


More information about the cairo mailing list