Hi Behdad,<div><br></div><div>Attached is a patch that does what you suggest, with a few differences.</div><div>It's an initial stab, but it works as expected.</div><div><br></div><div>Included in this patch are some changes to cairo-ft-font.c that hooks into this private function.</div>
<div>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.</div><div><br></div><div>Please review, comment, criticize. I learned a lot writing this patch.</div>
<div><br></div><div>Lance</div><div><br><div class="gmail_quote">On Mon, Feb 2, 2009 at 3:15 AM, Behdad Esfahbod <span dir="ltr"><<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Yeah, ARGB32 in the input doesn't make sense. Now lets stop designing and<br>
writing code over email. :)<br>
<font color="#888888"><br>
behdad<br>
</font><div class="Ih2E3d"><br>
Lance Hepler wrote:<br>
> Hi Behdad,<br>
><br>
> Haha! Good thing. I've already started working on it. And that's about<br>
> the way I've set it up.<br>
> One question I have is whether I'll need to handle ARGB32 surfaces, as<br>
> the current code simply handles 3x (width/height) CAIRO_FORMAT_A8<br>
> surfaces. Should I just assume we'll only need it for the A8 case and<br>
> assert so in the function? Expanding the code to filter ARGB32 surfaces<br>
> would be ... tricky.<br>
><br>
> Lance<br>
><br>
> On Sat, Jan 31, 2009 at 10:35 PM, Behdad Esfahbod <<a href="mailto:behdad@behdad.org">behdad@behdad.org</a><br>
</div><div><div></div><div class="Wj3C7c">> <mailto:<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>>> wrote:<br>
><br>
> Hi Lance,<br>
><br>
> The filtering should go into a file of its own for now.<br>
> "cairo-lcd-filter.c"<br>
> works for me. The public API will look like what was committed and<br>
> reverted.<br>
> The main function in that file will take a cairo image surface and a<br>
> filtering mode and subpixel order, and returns a new surface that<br>
> has the<br>
> filtering results...<br>
><br>
> The rest of the work will be done in cairo-scaled-font.c. Note that<br>
> I need to<br>
> do some code reshuffling before this can be hooked up.<br>
><br>
> Thanks,<br>
> behdad<br>
><br>
> Lance Hepler wrote:<br>
> > Hi Owen,<br>
> ><br>
> > It seems that Behdad is not interested in disturbing the ability to do<br>
> > native-style rendering. He's interested in making it possible to do<br>
> > rasterization in cairo so that animation of text can be done well.<br>
> This<br>
> > is an excellent point.<br>
> ><br>
> > I don't see any issues in that at all. The question is, how/where do I<br>
> > want to put a new file/funtions that contains the lcd filtering code<br>
> > that I've ripped from freetype? And how do we want this API to look,<br>
> > even if we keep it private for cairo until we're happy with it?<br>
> ><br>
> > I'm perfectly fine ripping out the sections of freetype that do the<br>
> > filtering (I'm sorry D. Turner!), making another file (seems best,<br>
> since<br>
> > we want this filtering available for all backends, not just freetype)<br>
> > for doing lcd filtering in the cairo src directory, and hooking the<br>
> > calls in cairo-ft-font.c to use this code to filter instead of<br>
> Freetype.<br>
> > Looking over ftlcdfil.c it doesn't seem to be too difficult to adjust<br>
> > the code to work within a cairo-only context. As long as we keep<br>
> pulling<br>
> > in the preferences from fontconfig, there shouldn't be any<br>
> regressions,<br>
> > and I don't foresee tremendous difficulty in making this<br>
> adjustment. Of<br>
> > course, I haven't looked at the formats we're using to keep the other<br>
> > backends bitmapped glyphs, so maybe I'm just naive.<br>
> ><br>
> > Anyways, doing this now will give us the immediate benefit of having<br>
> > these improved filtering methods finally upstream, which would be of<br>
> > benefit to the unnamed distros that are currently using one version of<br>
> > the 10301 patch or another. That, and I'm sure users of those distros<br>
> > that are not using the 10301 patches will benefit from/be grateful for<br>
> > the improved font rendering. Really, I just want to go the route that<br>
> > will upstream these filtering abilities as soon as possible.<br>
> ><br>
> > I am really interested and anxious to see the putative improvements in<br>
> > font rendering Behdad has planned (subpixel positioning for<br>
> > unhinted/slightly-hinted fonts might be really nice! (they aren't<br>
> really<br>
> > affected by the lsb/rsb deltas)).<br>
> ><br>
> > Nicolaus (Lance)<br>
> ><br>
> > On Thu, Jan 29, 2009 at 11:48 AM, Owen Taylor <<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a><br>
> <mailto:<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a>><br>
</div></div><div><div></div><div class="Wj3C7c">> > <mailto:<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a> <mailto:<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a>>>> wrote:<br>
> ><br>
> > On Thu, 2009-01-29 at 01:39 -0500, Behdad Esfahbod wrote:<br>
> > > Hi Lance,<br>
> > ><br>
> > > I agree with most of your positions. However, my long term plan<br>
> > is to move<br>
> > > glyph rasterization away from FreeType and into cairo, and that<br>
> > includes<br>
> > > subpixel rendering. I think the API should wait till that<br>
> > happens. In that<br>
> > > case Carl's remaining issues will be moot as we can do the same<br>
> > filtering on<br>
> > > all platforms and it will not be FreeType-specific anymore.<br>
> ><br>
> > One thing to be concerned about is that matching the system<br>
> rendering.<br>
> > Whether text looks good is not just a matter of whether it<br>
> looks good in<br>
> > isolation, but whether it matches other text on the screen in<br>
> contrast<br>
> > and other characteristics.<br>
> ><br>
> > For example, if you take some text rendered on the Mac, and<br>
> drop it onto<br>
> > a Windows desktop, the typical reaction will be that it is<br>
> fuzzy. Taking<br>
> > text the other way may produce complaints about letter shapes<br>
> or color<br>
> > fringing.<br>
> ><br>
> > - Owen<br>
> ><br>
> ><br>
> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>