[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