Re: OpenGL, xserver, and anti-aliased fonts

I thought we had worked through the sub-pixel rendered text with OpenGL problem
a couple of months ago and come up with a solution. Wasn't it some neat trick
using a blend function? Or are we concluding that sub-pixel rendering can't be
done with hardware compositing?

--- Jim Gettys <[email protected]> wrote:
> 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
> 
> 
> _______________________________________________
> xserver mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xserver


=====
Jon Smirl
jonsmirl-/[email protected]

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com