Hi Robert and Mathias, back after the weekend.
> I do also wonder about formalizing the extension set up. In essence we are > initializing bool relating to feature supported yes/no, and the function > pointers. Currently it's all rather adhoc how this is all done. The whole > area could do with a major refactor to make things more coherent. For refactoring, three ideas are coming to my mind (please, append yours): 1. I would like to have GL_FEATURE(...) macro that would register me a bool that would be set to a yes/no depending on some evaluation (extension support, GL version, GLSL version, number of texture samplers, etc.). I should be able to get its value on per-contextID basis. and GL_FUNCTION(....) macro that would register me a function that would be automatically initialized (per-context) during realize. But I am worrying about performance hit as looking-up the function by contextID might take some time. Thus, I would prefer another approach. 2. I would like to have a class, say GraphicsContextMediator, and I would append members by macros named, say, GL_FEATURE(...) (for an auto-detected bool) and GL_FUNCTION(...) (for an auto-binded OpenGL function). They would automatically initialize their content on the GraphicsContextMediator construction. The construction would be triggered by a proxy during GraphicsContext::realize(). GraphicsContextMediator could be a private class, if we want. It can be inside any .cpp file, providing GL informations wherever programmer puts it, including StatsHandler. This way, StatsHandler might stop out-source OpenGL function pointers from Drawable::Extensions, but they might be moved to its own code, possibly improving the code quality. 3. Still one more option - to use existing osg::isExtensionOrVersionSupported() and similar functions and make them work properly even outside active graphics context. However, this functionality would probably not serve for advanced things like getting number of texture samplers or max uniforms, etc. Just extensions and OpenGL version and nothing more. Still more ideas by anyone? > For a registry of objects to initialize my inclination would be to have a > registry of all OpenGL objects types, which is essentially osg::Drawable > and osg::StateAttribute's, perhaps one could just have a registry of > osg::Object and then cast these to Drawable or StateAttribute then call a > function to do the initialize. I would also be inclined to have a > initializeExtensions(State&) method that Drawable and StateAttribute have > that is called. This approach would mean you wouldn't need to worry about > the specifics of the various extension classes. However, this might not be > ideal subdivision for this feature. I agree, just I do not understand - what do you mean by "registry of OpenGL object types"? Object type is not an instance, thus it does not have a pointer that could be registered in a list. Could you clarify for me how it would work? Thanks, John On Friday 20 of September 2013 14:16:36 Robert Osfield wrote: > Hi John and Mathias, > > I haven't discounted or approve of any one option yet, but have done a > little more thinking. Mathias's suggestion of a flag whether the realize > should invoke all the initialization steps or leave it to lazy > initialization would be sensible if we wish to avoid the cost of > initializing all extensions sounds reasonable compromise. Although this > might leave application developers need to support both lazy and realize > initializations in their applications yet in case. > > For a registry of objects to initialize my inclination would be to have a > registry of all OpenGL objects types, which is essentially osg::Drawable > and osg::StateAttribute's, perhaps one could just have a registry of > osg::Object and then cast these to Drawable or StateAttribute then call a > function to do the initialize. I would also be inclined to have a > initializeExtensions(State&) method that Drawable and StateAttribute have > that is called. This approach would mean you wouldn't need to worry about > the specifics of the various extension classes. However, this might not be > ideal subdivision for this feature. > > I do also wonder about formalizing the extension set up. In essence we are > initializing bool relating to feature supported yes/no, and the function > pointers. Currently it's all rather adhoc how this is all done. The whole > area could do with a major refactor to make things more coherent. > > More widely I do also wonder whether we should split up the scene graph > data from the OpenGL implementation, so that the scene graph data object > would have a list of implementations, these implementations might contain > handles to extensions or OpenGL object id's a handle to the extension. > > Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
