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
