Hi Robert, > I'm happy to help out, but we have to work out is whether it's worth > attempting to do all this before 3.0.
These extensions are of very high priority for me. Unfortunately, my boss priorities are now some issues and improvements on osgQt. When I finish it, I will be back to this topic and I will send some first new API proposal. Then, I will be happy for your comments. We will see how it will be with the time estimation and 3.0 at that time. Thx, John > ------------ Original message ------------ > From: Robert Osfield <[email protected]> > Subject: Re: [osg-submissions] New GLExtension architecture > Date: 11. 3. 2011 22:01:33 > ---------------------------------------- > Hi Jan, > > Just a quick reply as it's now the weekend as far my kids are concenced ;-) > > On Fri, Mar 11, 2011 at 7:51 PM, PC John <[email protected]> wrote: > > 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()). > > My current inclination would be to a GLFeatures container per context, and > have this agregrate a list GLFeature objects, where the GLFeature would be > a base class > for the localized GLFeature implementation. The GLFeature object would > be equvilant > to current Drawable::Extensions structure. THis would allow us to > keep the features > implemented locally to the use of them rather than centrally, and thus keep > the extensibiltiy that is a strong point of the current scheme. > > > 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? > > GraphicsContext already calls osg::State::initializeExtensionProcs() > which is similar > in role to what we are discussing for GL feature initialization, it > just focused on osg::State > extension functions. > > >> 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. > > In intersecting approach, I don't think it's quite flexible enough > though, as it won't cope with new versions of OpenGL coming out with > the bitmask being extended. Also we need to cope with multiple > extension names as well as version numbers. It might be better to > have property object that adapts different constraits, and then have > ability to handle multiple constraint properties. i.e. > > isFeatureSupported(GLVersion(2.0), > GLESVersion(2.0), > GLExtensionStr("gl_FunkyFunc_ARB"), > GLExtensionStr("gl_FunkyFunc_EXT")); > > We could possible have handling of <, <=, > and >= version checked > within this property approach as well using different properties. > > > If considering to drop the extension string then we will lose disable > > functionality. Thoughts? > > The extension disable feature would naturally have to become a feature > disable feature. I would suggest a scheme where features could be > named via a series of names.with.full.stop.sperators, to enalbe us to > disable a how family of associated features or indivial features > within this. > > One could also disable the features by just getting the appropriate > GLFeature structure and disabling it directly. > > > 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. > > Just this is what I was thinking about with the above suggestion of a > GLFeatures container with GLFeature > implementations within it. We'd need a GLFeatureRegistry as well for > the proxies to register with tell the GLFeatures container which > GLFeature implentations it has to iniatialize. > > As well as options to keep local pointers for quick access I believe > we need to be able to call GL features directly rather than through > function pointers. For instance if you compile against GL2 or above > then VBO and vertex array functions can be just called directly, there > is no need to check at runtime for their availability and then call > through function pointers. It may be possible to enable this > inlining via the individual GLFeature interfaces i.e > > class MyGLFeature : public GLFeature > { > public: > > #if COMPILE_WITH_FUNKY_FUNCTION > inline glFunkyFunc(paramters) const { ::glFunkyFunc(parameters); ) > #else > // use function pointer > inline glFunkyFunc(paramters) const { _glFunkyFunc(parameters); ) > #endif > > } > > >> 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... > > I'm happy to help out, but we have to work out is whether it's worth > attempting to do all this before 3.0. > > > 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. > > There GLFeature structures can easily be initialized on demand when > objects are rendered for the first time, so this wouldn't need to the > proxy support, it's only the central iniatialization that requires the > list of all GLFeature implementations to setup. > > If you create the window, then load plugin which implements an > extension, and you want to query a feature then you'll just need to > make sure that feature is initialized by the appropriate GL context. > Very few users will be needing to do exactly this, and if they are > they will just need to mindful of order of initialization and feature > testing. > > Robert. > _______________________________________________ > 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
