Re: OpenGL, xserver, and anti-aliased fonts

Algorithms for doing sub-pixel rendered text under OpenGL would be a good topic
for a presentation the xserver conference. 

--- Brian Paul <brian.paul-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org> wrote:
> 
> 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
> > 
> 
> 
> 
> _______________________________________________
> 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