Wojciech Lewandowski wrote:
Lots of older OpenGL extensions are now included in OpenGL specification
(rel. 3.2). I'd like to propose a small cleaning movement of OSG sources
Hi Wojtek --
I agree that the kind of scrubbing you've proposed would break backwards
compatibility, as Gordon described. However, OSG definitely needs some
clean up and fixes in the area of querying for feature support and
obtaining the appropriate entry points.
I was waiting for Robert to chime in on this thread, but I think I speak
on his behalf when I say he supports a clean up effort. In the thread
"OpenGL capture/logging in OSG" from mid-December, Robert said: "I
would, however, be happy to see a more formalized system for extension
setup, as the current distributed approach has let the styles of
implementation diverge as a series of different developers have got
their hands dirty contributing code."
So now we just need to decide exactly what we mean by clean up. :-)
First, I don't want to limit the discussion by using the word
"extension". We should consider cleaning up code that queries for the
presence of OpenGL features. They might be extensions, or they might be
core functionality.
In most any OpenGL literature that you read, querying for feature
support at run time should be done as follows;
If the feature is part of the run time GL version's core spec
Use the core interface
else if an ARB extension supports the feature
Use the ARB interface
else if an EXT extension supports the feature
Use the EXT interface
else
Similar checks for possibly multiple vendor extensions
OSG should do this as well, but in most cases it doesn't. Instead, OSG
simply checks for the availability of entry points and uses them if
present. This is a dangerous approach, as many drivers contain entry
points for the purpose of testing beta features. This is one thing I'd
definitely like to see cleaned up.
(In fact, this is currently a bug in OSG. If I open a v3.0 context, OSG
uses the v3.2 core FBO entry points exposed by my device driver, not the
ARB FBO extension interface.)
I'd also like to see a function pointer name clean up effort. Function
pointers should be named generically ("glGenBuffers", not
"glGenBuffersARB" or "glGenBuffersEXT"). In 90% of all features, we're
just concerned with which feature it references, not which specific
extension interface is being used. With an initialization system like I
described in the pseudocode above, or even with OSG as it currently
stands today, the function pointer could be loaded with just about any
interface entry point, so it should have a name that isn't
interface-specific.
Another thing to consider is the wrapper pattern currently employed in
many of OSG's OpenGL function pointers. The wrapper pattern has the
following form:
void glFunctionWRAPPER( ... )
{
if( _glFunction != NULL )
_glFunction( ... );
else
Log an error
}
Checking on the validity of the pointer every time app code calls into
the wrapper seems a little heavy. I'd rather see a system that lets
calling code query for the presence or absence of a feature. If the
feature is absent, calling code should avoid calling into the feature's
function wrappers, eliminating the need for per-wrapper checks for
function pointer validity. (I believe this is a better approach for
calling code too, as that code will usually want to take one path or
another based on the presence or absence of certain GL features.)
(Note that I'm not opposed to wrappers in general. An OpenGL wrapper
system should probably be at the core of every major OpenGL app. It
simply needs to be designed for lightweight production builds.)
There's the topic of centralization. I've proposed moving all OpenGL
function pointers an related initialization into a single class. Among
other reasons, this would make it easier for future developers to ensure
that they're implementing feature query and initialization consistent
with OSG's best practice. But Robert has expressed disagreement with
this approach (again, see the thread "OpenGL capture/logging in OSG").
So for now, any type of new system we implement for feature querying and
initialization will need to be cut and pasted across several source files.
Finally, another thing to consider is replacing our existing feature
query infrastructure with something like GLEW. GLEW is lightweight,
easily extensible, and already handles much of what we need for GL
feature support. But we have discussed this in the past, and if I
remember correctly Robert was opposed to GLEW on the grounds of the new
third party dependency it would require.
Well, I know this is a bit more extensive that the slow, piece-by-piece
clean up effort that you had in mind with your original post. But I
wanted to throw this out there for consideration by you and the rest of
the community.
If we can all come to some consensus on how to proceed, we can start
making changes and submissions. (Hopefully this doesn't fall by the
wayside, as Sukender's proposal for plugin transformations did.)
-Paul
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
