Hi John, Thanks for the updated extension work. I've now down a first pass review, but can't yet claim to have a full picture of the changes, strengths, weakness and consequences of the changes. I'll try do provide some first pass feedback.
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. 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. Another approach that you seem keen on, but one I've objected to all along, and this is centeralizing all the extension structures. If we centeralize extension/feature step up entirely then we loose the consistency of how we handle external extensions to the scene graph. 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. 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. Thoughts? Robert. 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-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
