Hi Behdad,<div><br></div><div>Attached is a patch that does what you suggest, with a few differences.</div><div>It&#39;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&#39;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">&lt;<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>&gt;</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&#39;t make sense. &nbsp;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>
&gt; Hi Behdad,<br>
&gt;<br>
&gt; Haha! Good thing. I&#39;ve already started working on it. And that&#39;s about<br>
&gt; the way I&#39;ve set it up.<br>
&gt; One question I have is whether I&#39;ll need to handle ARGB32 surfaces, as<br>
&gt; the current code simply handles 3x (width/height) CAIRO_FORMAT_A8<br>
&gt; surfaces. Should I just assume we&#39;ll only need it for the A8 case and<br>
&gt; assert so in the function? Expanding the code to filter ARGB32 surfaces<br>
&gt; would be ... tricky.<br>
&gt;<br>
&gt; Lance<br>
&gt;<br>
&gt; On Sat, Jan 31, 2009 at 10:35 PM, Behdad Esfahbod &lt;<a href="mailto:behdad@behdad.org">behdad@behdad.org</a><br>
</div><div><div></div><div class="Wj3C7c">&gt; &lt;mailto:<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt; &nbsp; &nbsp; Hi Lance,<br>
&gt;<br>
&gt; &nbsp; &nbsp; The filtering should go into a file of its own for now.<br>
&gt; &nbsp; &nbsp; &nbsp;&quot;cairo-lcd-filter.c&quot;<br>
&gt; &nbsp; &nbsp; works for me. &nbsp;The public API will look like what was committed and<br>
&gt; &nbsp; &nbsp; reverted.<br>
&gt; &nbsp; &nbsp; &nbsp;The main function in that file will take a cairo image surface and a<br>
&gt; &nbsp; &nbsp; filtering mode and subpixel order, and returns a new surface that<br>
&gt; &nbsp; &nbsp; has the<br>
&gt; &nbsp; &nbsp; filtering results...<br>
&gt;<br>
&gt; &nbsp; &nbsp; The rest of the work will be done in cairo-scaled-font.c. &nbsp;Note that<br>
&gt; &nbsp; &nbsp; I need to<br>
&gt; &nbsp; &nbsp; do some code reshuffling before this can be hooked up.<br>
&gt;<br>
&gt; &nbsp; &nbsp; Thanks,<br>
&gt; &nbsp; &nbsp; behdad<br>
&gt;<br>
&gt; &nbsp; &nbsp; Lance Hepler wrote:<br>
&gt; &nbsp; &nbsp; &gt; Hi Owen,<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; It seems that Behdad is not interested in disturbing the ability to do<br>
&gt; &nbsp; &nbsp; &gt; native-style rendering. He&#39;s interested in making it possible to do<br>
&gt; &nbsp; &nbsp; &gt; rasterization in cairo so that animation of text can be done well.<br>
&gt; &nbsp; &nbsp; This<br>
&gt; &nbsp; &nbsp; &gt; is an excellent point.<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; I don&#39;t see any issues in that at all. The question is, how/where do I<br>
&gt; &nbsp; &nbsp; &gt; want to put a new file/funtions that contains the lcd filtering code<br>
&gt; &nbsp; &nbsp; &gt; that I&#39;ve ripped from freetype? And how do we want this API to look,<br>
&gt; &nbsp; &nbsp; &gt; even if we keep it private for cairo until we&#39;re happy with it?<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; I&#39;m perfectly fine ripping out the sections of freetype that do the<br>
&gt; &nbsp; &nbsp; &gt; filtering (I&#39;m sorry D. Turner!), making another file (seems best,<br>
&gt; &nbsp; &nbsp; since<br>
&gt; &nbsp; &nbsp; &gt; we want this filtering available for all backends, not just freetype)<br>
&gt; &nbsp; &nbsp; &gt; for doing lcd filtering in the cairo src directory, and hooking the<br>
&gt; &nbsp; &nbsp; &gt; calls in cairo-ft-font.c to use this code to filter instead of<br>
&gt; &nbsp; &nbsp; Freetype.<br>
&gt; &nbsp; &nbsp; &gt; Looking over ftlcdfil.c it doesn&#39;t seem to be too difficult to adjust<br>
&gt; &nbsp; &nbsp; &gt; the code to work within a cairo-only context. As long as we keep<br>
&gt; &nbsp; &nbsp; pulling<br>
&gt; &nbsp; &nbsp; &gt; in the preferences from fontconfig, there shouldn&#39;t be any<br>
&gt; &nbsp; &nbsp; regressions,<br>
&gt; &nbsp; &nbsp; &gt; and I don&#39;t foresee tremendous difficulty in making this<br>
&gt; &nbsp; &nbsp; adjustment. Of<br>
&gt; &nbsp; &nbsp; &gt; course, I haven&#39;t looked at the formats we&#39;re using to keep the other<br>
&gt; &nbsp; &nbsp; &gt; backends bitmapped glyphs, so maybe I&#39;m just naive.<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; Anyways, doing this now will give us the immediate benefit of having<br>
&gt; &nbsp; &nbsp; &gt; these improved filtering methods finally upstream, which would be of<br>
&gt; &nbsp; &nbsp; &gt; benefit to the unnamed distros that are currently using one version of<br>
&gt; &nbsp; &nbsp; &gt; the 10301 patch or another. That, and I&#39;m sure users of those distros<br>
&gt; &nbsp; &nbsp; &gt; that are not using the 10301 patches will benefit from/be grateful for<br>
&gt; &nbsp; &nbsp; &gt; the improved font rendering. Really, I just want to go the route that<br>
&gt; &nbsp; &nbsp; &gt; will upstream these filtering abilities as soon as possible.<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; I am really interested and anxious to see the putative improvements in<br>
&gt; &nbsp; &nbsp; &gt; font rendering Behdad has planned (subpixel positioning for<br>
&gt; &nbsp; &nbsp; &gt; unhinted/slightly-hinted fonts might be really nice! (they aren&#39;t<br>
&gt; &nbsp; &nbsp; really<br>
&gt; &nbsp; &nbsp; &gt; affected by the lsb/rsb deltas)).<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; Nicolaus (Lance)<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; On Thu, Jan 29, 2009 at 11:48 AM, Owen Taylor &lt;<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a><br>
&gt; &nbsp; &nbsp; &lt;mailto:<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a>&gt;<br>
</div></div><div><div></div><div class="Wj3C7c">&gt; &nbsp; &nbsp; &gt; &lt;mailto:<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a> &lt;mailto:<a href="mailto:otaylor@redhat.com">otaylor@redhat.com</a>&gt;&gt;&gt; wrote:<br>

&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; On Thu, 2009-01-29 at 01:39 -0500, Behdad Esfahbod wrote:<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; &gt; Hi Lance,<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; &gt; I agree with most of your positions. &nbsp;However, my long term plan<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; is to move<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; &gt; glyph rasterization away from FreeType and into cairo, and that<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; includes<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; &gt; subpixel rendering. &nbsp;I think the API should wait till that<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; happens. &nbsp;In that<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; &gt; case Carl&#39;s remaining issues will be moot as we can do the same<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; filtering on<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; &gt; all platforms and it will not be FreeType-specific anymore.<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; One thing to be concerned about is that matching the system<br>
&gt; &nbsp; &nbsp; rendering.<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; Whether text looks good is not just a matter of whether it<br>
&gt; &nbsp; &nbsp; looks good in<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; isolation, but whether it matches other text on the screen in<br>
&gt; &nbsp; &nbsp; contrast<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; and other characteristics.<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; For example, if you take some text rendered on the Mac, and<br>
&gt; &nbsp; &nbsp; drop it onto<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; a Windows desktop, the typical reaction will be that it is<br>
&gt; &nbsp; &nbsp; fuzzy. Taking<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; text the other way may produce complaints about letter shapes<br>
&gt; &nbsp; &nbsp; or color<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; fringing.<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; &nbsp; &nbsp; - Owen<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>