Re: 2D antialiased graphics using OpenGL
"Martijn Sipkema" <[email protected]>
| Newsgroups | gmane.comp.freedesktop.xserver |
|---|---|
| Message-ID | <00a001c3c09a$5faaee00$161b14ac@boromir> |
[...] > 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