Concepts

Using texture mapping for geometry antialiasing is not a new idea. I found descriptions and presentations about it, but no actual code. The basic idea is to replace the original primitive with texture mapped triangles, as illustrated:

The texture applied to the triangles is simply an antialiased circle. Slices of the circle are stretched out for the line and triangle cases. To accommodate fractionally variable primitive sizes, we can generate the circle texture at an arbitrary maximum size and generate mipmaps for smaller sizes. Trilinear mipmapping will then approximate a texture for any desired size.

Implementation

My implementation, dubbed "glAArg" (OpenGL AntiAliased rendering glue), has two basic parts:

First, the texture. The circle needs to retain a one pixel empty border around it at every mip level, for blending. Ideally GL_ARB_texture_border_clamp could be used for this, but that extension is not available on all GPUs, so I fell back on a less efficient but universally supported approach. As shown, a 2D texture four times larger than the desired circle size is generated; texture REPEAT mode wraps the empty space around all sides of the circle. The circle itself is drawn into the texture with 8-way symmetry and variable exponential falloff from the center to the edge (sharp falloff pictured.)

Second, I made a set of wrapper APIs which intercept normal immediate mode GL calls and queue their data to do the right thing when enough vertices have been submitted for the current primitive type. For example, glAAVertex2f(x, y) will buffer the first vertex of a line segment. When the second vertex is submitted, it will then calculate eight vertices to project a rectangle and two endcaps around the line, and perform a real submit to the GL. If the hardware supports it, the calculated vertices / colors / texture coordinates are stored in a large array and submitted in chunks using VAR. The APIs are written in plain C and have been compiled into a GLUT demo app under Mac OS X, Linux, and Windows.

Results

Here is the test pattern rendered on four different GPUs with texture antialiasing:

The results are not quite bit-for-bit identical, due to tiny differences in the texture filtering between GPUs, but they are nearly identical, despite the very different results the same GPUs had with regular antialiasing and FSAA. In addition, the quality is better than any of the previous approaches, and in some cases arguably better than Quartz:

• Quartz's rounded line end caps "pop" into existence at 1.0 px. By insetting the line ends 0.5 px on either end, the textured end caps grow smoothly with the line width, best visible in test I.
• Quartz's points fade to transparent a bit too quickly in test C. By fudging the highest mipmap levels, the textured points stay a little brighter in tests B and C.
• Due to both of the above, note that test L now looks identical to test C.

And some things are worse:

• There is some blur at the edges of points/lines at odd sizes due to the mipmap interpolation. This is most visible in test J. For my applications this is tolerable but it would not be acceptable for an "official" implementation.
• Depending on the GPU, there is some slight diagonal artifacting near the center of test N (but still very close to Quartz, and better than any of the other OpenGL cases.)
• There is a 0.5 px border around triangles. This is a bug.

There are also some extra things that can be done in my textured implementation:

• Varying the circle texture's exponential falloff allows "spherical" points and lines.
• "Spherical" points can be cheaply light sourced for a pseudo-3D look.
• Triangle borders can be expanded, which when combined with variable falloff results in "fuzzy" triangles.

Performance

So now you are thinking, surely this quality comes at a huge speed hit? Well, yes and no. On the plus side, some operations that would require a state change in OpenGL (and thereby prevent using VAR for acceleration) such as setting the point size or line width can now be avoided, since these properties are calculated manually anyway. This means that for cases where the size of every primitive changes, the texture approach ends up being faster than regular antialiasing, because it can be accelerated with VAR. And in any case, it is much faster than Quartz.

On the minus side, of course there is a lot of extra geometry calculation to do, and three or four times as many vertices to transform and render. Triangles in particular are a lot slower. Naturally, my implementation could be further optimized. For example several areas are ripe for Altivec acceleration. And on modern GPUs, ultimately it should be possible to implement all of the geometry projection as vertex shader programs.

The exact performance of course depends on both the speed of the CPU and the GPU's vertex and fillrate limitations. Here is a chart benchmarking various machines in all of the rendering modes, counting thousands of points/lines/triangles drawn per second:

• The performance test alternates between drawing points, lines, and triangles with random colors, sizes/widths, and positions. Points and lines are drawn 20,000 times per frame, triangles 10,000. Each type of primitive is drawn for 5 seconds before switching to the next. Frames are swapped as fast as possible with VBL sync (60Hz cap on all tested systems.) Thus there is a theoretical max of 1.2 million for points and lines and 600 thousand for triangles. High performance systems are able to saturate this test.
• "Random" is actually repeatably pseudo-random so as to allow consistent tests across machines.
• Because of extremely slow performance, less primitives are drawn per frame for software AA triangles and Quartz lines and triangles. The benchmark numbers (all 0) are still accurate, this is done only to prevent the test from lasting 30 minutes. Quartz is extra slow on these tests because it does not have native support for gradient-filled shapes, so an expensive (and unoptimized) shading and image blending operation has to be done. Software AA triangles are just terribly slow on their own.
• 0 means less than 500 / second, typically it is around 150.
• In OpenGL modes (except Texture AA) all primitives are submitted via immediate mode. This is required for points and lines due to the size/width changing, but for triangles, better performance could be had by using VAR.
• Fillrate is a factor here; the line and triangle tests scale the primitive size with the window size. The backbuffer clear and swap also has some impact with large window sizes. The primitive sizes have been deliberately chosen such that, on fast systems with the default small window size, fillrate impact is minimized in Texture AA mode but still shows detrimental effect in FSAA modes.
• Some of the FSAA numbers are misleading, because due to sizing bugs only one half or one quarter the intended number of pixels are drawn. Correct behavior would results in lower scores.
• None of the modes should be considered optimized. My usage of Quartz in particular is very unoptimal (I wrapped NSBezierPath with the OpenGL API, and don't use CoreGraphics directly.)

Summary

The screenshots should convince you that the texture antialiasing quality is roughly equal to Quartz, and much better than any other OpenGL approach.

From the benchmark chart, we can see:

• FSAA can have very visible impact (i.e. 600->301->201->150 thousand triangles/sec on Radeon 9800.)
• Texture AA points usually outperform any other mode's points, by up to 400% depending on the system.
• Texture AA lines are anywhere from 30% to 250% of the speed of Hardware AA lines, depending on the system. They usually outperform the best FSAA mode, if we account for the FSAA sizing bugs.
• Texture AA triangles are roughly 30% to 50% of the speed of Hardware AA triangles.
• Depending on the primitive type and the CPU/GPU speed ratio, Texture AA outperforms Quartz by somewhere between 2,000% and 400,000%.

So there is a definite speed hit compared to regular OpenGL rendering overall, but in certain situations (randomly sized points) it can actually be faster. It is much faster than Quartz at nearly the same quality, and for my applications, Quartz is the only viable alternative given all the inconsistencies and problems with other OpenGL antialiasing methods.

Of course Texture AA is not a replacement for Quartz. It only draws a few types of antialiased shapes, nothing else. It is also subject to other limitations of OpenGL, such as maximum window size, which Quartz does not have. But for my needs it is a clear win.

Source Code

The current version of glAArg is 0.2.2: