Re: OpenGL, xserver, and anti-aliased fonts

On Fri, Mar 05, 2004 at 09:21:17AM -0500, Jim Gettys wrote:
| I looked at your OpenGL AA text in the graphs.
| 
| It does not come close to that we get now with the Xft
| technology.  ...

I didn't claim that it did -- I only offered some rationale and a
proof-of-concept for the rendering method in hopes of generating
interest from people who have more time to work on it than I do.  But
more on this below.

Fundamentally, to get resolution-independent graphics, you need to deal
with geometric primitives rather than image primitives until as late as
possible in the rendering pipeline.  Thanks to accelerator hardware, it
may now be practical to delay the final conversion from geometry to
image until the very end -- and gain some additional advantages in the
process.  I don't think that question has been answered, so I'm trying
to encourage everyone to keep it in mind.

|          ... The reason is that the Xft forms of AA
| work hard to keep the sharp edges of the characters on pixel
| boundaries, so only pixels that would be participating in jaggies
| are anti-aliased.

That may be the reason, but I don't think so.  (I haven't given you the
code or much explanation of how the renderer works, though, so there's
no way you could know.  Mea culpa.)

My renderer uses the hinted outlines from FreeType, and (modulo bugs)
samples only within the same regions that the FreeType rasterizer
samples.  So in theory, if I were to set the sampling rate and contrast
parameters to approximate what the FreeType rasterizer does, it would
generate the same pixels.  A similar argument could be made for other
rasterizers (if you're not using the FreeType rasterizer these days).

Looking at Keith's samples, the main things I noticed are: (1) They use
a different font with less frou-frou than the one I used. (2) Color
quantization is much coarser or contrast is much higher; I can't tell
which at a glance, but these are affected by dialable parameters in my
renderer and so are likely to be different.  (3) There's color fringing
in the intermediate-level pixels, indicating that they were antialiased
(at triple the horizontal resolution?) for use on an LCD display whereas
mine were antialiased for a CRT (and possibly would look noticeably
worse on an LCD).

So I believe what you're seeing is mostly consequences of an immature
implementation (mine) plus some differences in test conditions that
would have to be ironed out for an accurate comparison.  We'd be jumping
to conclusions if we said that there's a fundamental quality difference
between the two rendering methods.  (And I'm not aware of any
theoretical grounds for expecting one, anyway.)

| To do this in the OpenGL world is an interesting question;
| in the Xft technology, you have to adjust the outlines before
| rasterization and anti-aliasing, with knowledge of the pixels,
| so that the outlines are adjusted to pixel boundaries, avoiding
| AA effects on vertical and horizontal strokes.

I think we talked about this some in November, maybe prompted by a
question from Jon Smirl.  I suspect that vertex programs are capable
enough to do this, but you'd need to attach hinting information to each
control point.  I don't know enough about hinting to guess what form
that would take.

| Remember, the eye is an edge detector in nature.  It *really* likes
| sharp edges.

True in 3D as well as 2D. :-)

Allen