Re: 2D antialiased graphics using OpenGL

This is great information. Tackling the anti-aliasing "problem" is the 
next big step we have planned for libglc (OpenGL backend for Cairo). I 
would like to point out that neither I nor David (also working on 
libglc) are especially experienced OpenGL developers.  It seems there 
are a lot of competent OpenGL folx around here and all help or tips are 
much appreciated.

The bits can be fetched from the Cairo CVS: `cvs -d 
:pserver:anoncvs-gs45o/xk8Z54e/[email protected]:/cvs/cairo co libglc` or from 
www.cs.umu.se/~c99pnn/thesis

--
Peter Nilsson (c99pnn at cs.umu.se)

Allen Akin wrote:

>On Tue, Dec 09, 2003 at 05:14:58PM +0100, Martijn Sipkema wrote:
>| When doing 2D graphics using OpenGL one needs to draw front to
>| back using GL_SRC_ALPHA_SATURATE. ...
>
>That's one way to do it.
>
>All the antialiased drawing techniques are approximations.  Each has its
>advantages and disadvantages.  Off the top of my head, here are some of
>the techniques and tradeoffs:
>
>	Drawing front-to-back using GL_SRC_ALPHA_SATURATE.  Normally
>	used for drawing geometric primitives with pixel coverage
>	information ("smooth" points and lines and polygons in GL
>	terminology).  Advantages:  Good-quality results for silhouette
>	edges and shared edges.  Disadvantages:  Requires primitives to
>	be sorted; intersecting primitives cause artifacts; hardware
>	support is uneven.
>
>	Multipass using accumulation buffering.  Normally used for
>	full-scene antialiasing.  Advantages:  Works for essentially all
>	primitives in essentially all interrelationships and rendering
>	models; can incorporate other effects such as blurring moving
>	primitives; can yield very high quality results; permits fast
>	rough rendering with incremental improvement in interactive
>	applications.  Disadvantages:  Requires substantial extra
>	memory; is rarely hardware-accelerated in midrange and low-end
>	graphics cards; even with hardware acceleration is relatively
>	slow.
>
>	Multipass using blending.  Similar in concept to accumulation
>	buffered antialiasing.  Advantages:  Can be applied to full
>	scene or to any portion of a scene; generally faster and
>	requires less memory than accumulation buffering; accelerated
>	even on low-end cards; otherwise advantages are similar to
>	accumulation buffering.  Disadvantages:  Requires a simpler
>	rendering model ("painting" or "erasing" work well, but some
>	blending functions don't); getting the filtering parameters
>	right requires care; can be slow if very high quality results
>	are needed and geometry being drawn is complex and
>	geometry-processing rate is low.
>
>	Full-scene antialiasing using software supersampling.  (Drawing
>	to a high-resolution offscreen buffer, then filtering and
>	copying to the final target drawable.)  Advantages:  Works for
>	essentially all primitives, all interrelationships, all
>	rendering models; fast; well-supported.  Disadvantages: Requires
>	a lot of memory, yields only modest-quality results.
>
>	Full-scene antialiasing using hardware assist (typically
>	multisampling, sometimes supersampling).  Advantages:  Very
>	fast; works for all primitives, interrelationships, and
>	rendering models; well-supported in current hardware.
>	Disadvantages:  Some extra memory required (typically less than
>	for software supersampling or accumulation buffering); yields
>	decent-quality results but some people may not find them
>	acceptable for small text.  (Very high-quality results are
>	achieved on high-end systems, but not relevant in this
>	discussion.)
>
>I've skipped a few rarely-used methods, I've probably forgotten a few
>more, and certainly these short summaries are oversimplifying the
>tradeoffs.  It's best to think of them as just suggestions for further
>investigation.
>
>At the moment I'm interested in multipass using blending.  It seems to
>be the most flexible option with low memory requirements and good
>hardware support.  It handles intersections and near-approaches
>correctly, which compositing-based systems often can't, so it looks good
>for scenes with combined text and graphics.  It does place limitations
>on the rendering model, though, and I have no idea whether the toolkit
>and apps folks have thought about whether those would be acceptable.
>
>On the other hand, it's clear that the hardware vendors are putting most
>of their effort into multisampling.
>
>None of the methods described above take advantage of programmability at
>the vertex or fragment levels, so you can expect new variations to be
>developed.
>
>Allen
>
>_______________________________________________
>Xserver mailing list
>Xserver-u7BhqnqprCWvj1b/[email protected]
>http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/xserver
>
>  
>