2D antialiased graphics using OpenGL

Martijn Sipkema msipkema@sipkema-digital.com
Fri, 12 Dec 2003 11:26:15 +0100


[...]
> I know of hardware which can run at 10 bits per component; that has the
> undesired side effect of eliminating destination alpha bits for the
> beloved SRC_ALPHA_SATURATE rendering mode though.

Hmm, that sucks...

> Sometime soon, we'll have floating point pixel values which can easily be
> made linear.

Another solution would be the ability to have different visuals with or
without gamma correction. It seems some SUN workstations have this
feature, but I doubt any consumer hardware supports this; they only
seem to support one visual really.

> > I feel that if 8 bits per channel is not good enough, then one should
use
> > more, but I doubt it is really _that_ bad...
>
> This sounds more like a full-employment plan for graphics card vendors
> than a practical solution.  For 2D graphics, the reality is that geometry
> is such an insigificant part of the current user experience that minor
> errors in compositing results are not as important as reducing banding in
> continuous tone images.  We can improve the appearance of geometric
> objects by taking advantage of hardware accelerated gamma-correct
> compositing, or by doing that operation in software (Jim Blinn even
> provides nice code snippets for that...)

Well, hardware accelerated gamma-correct compositing may not be
available (and could probably be used to do hardware compositing of
a sRGB image to a linear color framebuffer if it were) and software
rendering is also not ideal.

Either hardware accelerated rendering is incorrect, or we suffer a loss
in quality when using a gamma corrected framebuffer.

I'm going to do some testing to see if using a gamma corrected framebuffer
is really that bad.

--ms