[cairo] Discussion: LCD Filtering API

[Lance Hepler]

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> 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>> 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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20090201/db011d7a/attachment.html