Hi Robert,
thanks for the first review. See comments in the text bellow.
> First up, my inclination would be to just have a single
> getGLExtensions/getGLFeatures() method in osg::GraphicsContext. I
> would also not push extension set up solely into osg::GraphicsContext
> as users do still use the OSG without any
> osg::GraphicsContext/GraphicsWindow - instead still use
> osgUtil::SceneView. Pushing the extension initialization into
> osg::State would be more sensible and flexible.
Having only getGLExtensions/getGLFeatures() without forwarding methods - it
can simplify the API. I can remove these. If you think that getGLFeatures will
be the better name, we can rename it, including the class (GLExtensions ->
GLFeatures) and maybe even the function
(osg::GLExtensions::isGLExtensionSupported() -> isGLFeatureSupported()).
I am still not sure about the initialization. Pushing it to osg::State would
resolve (at least) the compatibility with osgUtil::SceneView, while
initializing it in osgViewer::GraphicsWindow::realizeImplementation() is
probably what a programmer expects: Once he performed realize on his window,
it should be the most easy and convenient for him if he gets graphics window
internally fully initialized and ready for use (including osg::GLExtensions).
My impression was that it is the best for the programmer to get everything
ready after realize (including osg::State initialization). It came to my mind
that maybe, we can perform two initializations: One from realize and the
second from osgUtil::SceneView, while the second initialization attempt will
do nothing. What do you think about the topic?
> Now that we are supporting a wide range of OpenGL and OpenGL-ES
> versions I think we probably now need to start thinking in terms of GL
> features rather than extensions. This is really just name changes
> though, so structurally it wouldn't change the class design or object
> model we use. Conceptually it's possible an import step forward
> though, as we are no longer just talking about extensions to GL1.1 but
> whole different versions of GL where whole features may be absent that
> were available previously.
Maybe, we can modify
isGLExtensionSupported(float requiredGLVersion, const char *extension)
to
isGLExtensionSupported(enum requiredFeatureSet, const char *extension)
where
FeatureSet would be:
enum {
GL11 = 1 << 1,
GL12 = 1 << 2 | GL11,
GL13 = 1 << 3 | GL12,
...
GL21 = 1 << 7 | GL20,
GL30 = 1 << 8,
GL31 = 1 << 9 | GL30,
....
GLES10 = 1 << 24,
GLES11 = 1 << 25 | GLES10,
GLES20 = 1 << 26
} FeatureSet;
RequiredFeatureSet parameter should specify GL versions that provide the
required functionality.
If considering to drop the extension string then we will lose disable
functionality. Thoughts?
> [...]
> I would much rather see a scheme we we can keep the features
> implemented in a distributed manner, but provide the means of
> initializing the GL feature structures in a coherent central way.
This could be the way. If you prefer distributed approach, we can keep just
the map holding the list of extensions/features (GLExtensions
class) centralized. All the extension pointers can be distributed throughout
OSG and user code. Maybe, only the very frequently used functions can be kept
with GLExtensions class to alleviate the programmers work, their code and need
for multiple initialization.
> Using a proxy object scehe like used for plugins and serializer
> wrappers is one route we could go for this, we all the GL feature
> objects register themselves at startup, then when a context is
> realized the GL features objects are called one by one.
I am not an expert on this approach. I understand it in a way that there will
be a map from graphics context (or contextID) to structure containing all the
required function pointers. There will be some macros to automatize definition
and initialization of these pointers. If you can sketch macro names to control
this or to point me to the OSG file(s) that I can follow. I you do not have
time, do not mind...
One more thought: It may be more difficult to handle delay-loaded DLLs and
libraries, as their proxies can be executed after the window is realized.
John
> On Tue, Mar 8, 2011 at 10:13 AM, PC John <[email protected]> wrote:
> > Hi Robert,
> >
> > I am sending updated new OpenGL extension architecture based on trunk
> > revision 12150.
> >
> > It addresses following problems:
> >
> > 1. Average or "newbie" users are puzzled when trying to determine
> > particular extension availability. Only advanced users know that they
> > have to call osg::Drawable::getExtensions(contextID, false/true), while
> > true can be passed with active context only. To use false and not get
> > NULL, one has to initialize it when the context is current. So, you have
> > following options: [....etc...]. Even for advanced user, it is not a
> > piece of cake, and quite challenging for average user, in my opinion.
> >
> > 2. The extension related stuff is distributed over the OSG classes
> > providing no unified way to query particular extension support.
> > Introducing a new OpenGL extension support means to perform much of
> > coding (new ???::Extension class) or to reuse existing one like
> > Drawable::Extensions while it breaks encapsulation.
> >
> > 3. According to OpenGL documentation, shared contexts (the same
> > contextID) may support different extensions, different OpenGL version,
> > and even use different function pointers (MSDN2005 wglGetProcAddress
> > doc). The current approach is not robust enough to handle such
> > situations.
> >
> > I am sending a new approach addressing all these issues. You may notice
> > the code simplification when using the new approach. For example, about
> > the half of the file BlendFunc.cpp is now kept just for backward
> > compatibility and it can be removed in the future. Less code, more
> > productivity.
> >
> > Other classes ported to use the new approach are osg::State,
> > osg::Drawable, osg::BlendFunc, osg::OcclusionQueryNode,
> > osg::GraphicsContext,
> > osg::ArrayDispatchers, osgViewer::Renderer and osgViewer::StatsHandler.
> > Others can be included easily in the future.
> >
> > Feel free to comment the submission, suggest improvements, etc.
> > John
> >
> > _______________________________________________
> > osg-submissions mailing list
> > [email protected]
> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegra
> > ph.org
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph
> .org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
