Re: OpenGL, xserver, and anti-aliased fonts

Allen,

I looked at your OpenGL AA text in the graphs.

It does not come close to that we get now with the Xft
technology.  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.

Examine the text magnified in:
http://freedesktop.org/~keithp/screenshots/
In these examples, the text is subpixel rendered; you'll
see that by different colors in your blown up pixels.

So while AA text in OpenGL is clearly good for OpenGL based text,
particularly when you are doing 3D applications, it isn't
competitive for serious text applications; you suffer from
the fuzzies.

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 don't know how you'd achieve this in a 3D pipeline.  If
these 3D beasts are truly becoming fully programmable, maybe
it is possible...

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

On Thu, 2004-03-04 at 21:51, Allen Akin wrote:
> On Fri, Mar 05, 2004 at 12:45:47PM +1100, catach-m/[email protected] wrote:
> | I'd like to hear everyone's thoughts (or feel thier nudges in the right
> | direction!) ...
> 
> Like Carl said, check the archives for the first week of November; there
> was lots of discussion then.
> 
> Personally, I'm biased toward using geometric primitives (as opposed to
> image primitives) as much as possible -- there's much better hardware
> acceleration for them, they permit cleaner interaction between text and
> other objects, they can be used in compact display lists, they introduce
> fewer order-dependencies than image compositing, there may be
> opportunities to exploit the programmability of current-generation
> graphics chips, etc.  But there are also performance disadvantages on
> desktop hardware older than three years and on hardware without
> floating-point, so I suspect mine is a minority opinion.
> 
> Regardless of the rendering method you use, you'll need to be careful
> about hinting, subpixel positioning, and gamma correction.
> 
> Just for proof-of-concept, if you take a look at the graphs on
> 
> 	http://arden.org/solar
> 
> They're rendered using OpenGL.  The text in the axis labels and captions
> is antialiased.  It's drawn using a multipass method with all-positive
> filter kernel weights that I generated as part of a small optimization
> experiment.  I think the rendering parameters are decent for a CRT
> adjusted to meet the specs of sRGB, but would need to be changed
> slightly for LCD.
> 
> Again, there was much more detailed discussion back in November.
> 
> Allen
> 
> _______________________________________________
> xserver mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xserver
-- 
Jim Gettys <[email protected]>
HP Labs, Cambridge Research Laboratory