|
|
Antialiasing With some recent advents in 3D stuff including GL Tools, a few users have asked for me to include Antialiasing support for polygons. This isn't quite as simple as it sounds. In QC, there are 2 ways for an application to use it: With a QCView object, which constructs its own OpenGL Context, and QCRenderer, where you can feed it your own supplied context. The QC Application itself uses QCViews, and all the contexts are configured to be really boring: No accumulation buffer, no multisample support. These two features are essential for all the practical Antialiasing methods I've seen. Because the context is out of our control, we cannot easily change this (Actually, we could, but it would be Really Messy) With QCRenderer, you can configure the context to have those features, so there's no need to 'hack' them in. However, no existing patches expect to work with them, so there wouldn't be much to take advantage of this. So, Should I spend a few days exploring the internals of QC's context creation in QCView, and hack in Multisample/Accumulation Buffer support? How should this work when it's used in applications other than QC? If anyone has experience working with non-QC, QC-using application development, I'd love to hear your thoughts and experiences in this avenue. |
Given that this is going to be pretty hackish to begin with, I think it's probably safe to go with the caveat-emptor approach of "apply changes to all applications, not just QuartzComposerEditor".
I envision a patch (part of GL Tools) called "GL Context Settings" with a dropdown called FSAA, options "None", "2x", and "4x".
How would this affect:
Semi-related: have you seen http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html ? This seems to be the technique the new built-in "antialiased sprite" is using. As an alternative to the FSAA hack, would it be useful to add GL Tools patches that render using this technique?
This is (was?) one of the preferred ways to do decent AA without resorting to multisampling or FSAA. It's actually a pretty solution.
Points and lines don't appear to need AA, we just need to apply it to polys (GL Triangle and GL Quad).
could be a fun experiment.
Basic point and line AA already exists, right. But TexAA would solve the scaling-points problem with the Intel chipset, though, right? And would probably be faster than switching to software render mode? And from the other hardware-AA comparisons on that guy's site, TexAA would probably look a lot better for points and lines overall.
A patch would probably be unintuitive: it wouldn't take effect until either QC restarted or the composition is reloaded (best case, unconfirmed). Or maybe fullscreen/unfullscreen (so we could force the viewer to swizzle contexts when settings change I guess... how's that for a hack? ;)
There are 4 CGLContext creations when loading a composition, 6 when starting QC with a composition. When starting QC with a composition, only 1 of those 6 creations is after plugins load, so I can only hope that that's the Viewer's context. Closing the viewer has no effect on context creation.
Macro Patches: being in root doesn't matter, really, other than for easy access. I'm not aware of a simple way to limit patches on a per-composition level (only application-wide, which is easy). I'm sure it's possible, I just haven't done it. Patch limiting has, empirically, been extremely frustrating to users.
Render In Image and Composition loader: These should be managing their own contexts, so best case, we don't care, and worst case, we need to cook up some methods for them as well to duplicate functionality.
the output would definitely be more consistent.
the correct solution for intel's point (non-)scaling is a driver fix; TexAA can't be slower than software rendering, and is almost certainly faster on any reasonable hardware.
I think the reason points and lines all suck (as seen in that demo) is probably this: Nobody Uses Them. ;) This is an exaggeration, of course, but it's a pretty close approximation.
I think time would be better spent writing vertex/pixel shaders, honestly. Fixed Functionality needs to go away. An antialiasing fragment shader would 1) outperform both solutions above and 2) look consistent without adding additional geometry. (assuming this is possible, I'm just beginning to learn how fragment shaders work)
ah.. when you said "hack" I had assumed you were meaning something like "force the viewer to swizzle contexts" (even when not switching between fullscreen/windowed), so I was thinking the hypothetical patch would do that during its first execution.
a problem with this hack would be its use in other applications; apps using QCViews don't necessarily support going full-screen, so in those cases there's no way to force a context switch.
some news for AA