Re: OpenGL, xserver, and anti-aliased fonts

Brian Paul <brian.paul-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org>
Newsgroups gmane.comp.freedesktop.xserver
Organization Tungsten Graphics, Inc.
Message-ID <[email protected]>
That's a different issue.  During rasterization (converting the 
outlines to fragments/pixels) we want to nudge vertices and such so 
that horizontal and vertical segments exactly fall on pixel boundaries 
so they don't get partial coverage (and appear blurry).  BUT, for 
other pixels where we DO want partial coverage and need to do blending 
we may want separate blend factors for the R/G/B channels (i.e. for 
LCDs) - that's where the blend trick comes in.

I'm sure someone will correct me if I'm wrong.  I'm just getting up to 
speed on this stuff myself.

-Brian


Jon Smirl wrote:
> 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
> 
> _______________________________________________
> xserver mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xserver
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.