I tried your suggestion of clearing the s_gl* lists in ~GLException. I think it works, but have not been as thorough as I'd like yet.
Do I need to consider threading issues? Could someone be calling isGLExtensionOrVersionSupported at the same time ~GLExceptions is being called? I am using an older version of OSG, and when I send a version for review, I should probably make the change to current files. While I think the smaller fix would be appropriate for us, I like the alternate approach better. It would be: * put the things stored on the s_gl* lists into GLExtensions * pull out the code that gets the renderer string and extensions and have them called from GLExtensions constructor. * have isGLExtensionOrVersionSupported do GLExtensions::Get to get or create the GLExtensions for the given context ID and check that. * remove the s_gl* lists I can't update the version of OpenSceneGraph in this part of our cycle, but I may be able to make a change. I think I feel better with the change to clear the existing list element in ~GLException. But I think the other approach would be better for current OSG. andy -----Original Message----- From: Andy Skinner Sent: Wednesday, September 19, 2018 3:32 PM To: OpenSceneGraph Users <[email protected]> Subject: RE: [osg-users] context IDs Thanks, I'll take a look. I am hoping this will be more remove than replace, not needing multiple levels of caching. thanks andy -----Original Message----- From: osg-users <[email protected]> On Behalf Of Robert Osfield Sent: Wednesday, September 19, 2018 2:28 PM To: OpenSceneGraph Users <[email protected]> Subject: Re: [osg-users] context IDs Hi Andy, I have just had a quick look at the various s_* containers in GLExtensions.cpp and I think these are an old hang over that should be removed and replaced by code that is embedded into the GLExtensions object so that it can be constructed and destructed. Short of this refactor perhaps these data structures could be reset within the GLExtensions destructor. I don't have time to look into a fix right now, so either dive into the code yourself or avoid creating and destructor lots of contexts. Robert. Robert. On Wed, 19 Sep 2018 at 15:52, Andy Skinner <[email protected]> wrote: > > OK, I've digested some more. I see what you mean (I think) about ~State > clearing the GLExtensions object from the static map (s_extensions) defined > in GLExtensions.cpp. > > However, if the next GLExceptions::Get will make a new one, the GLExtensions > constructor will use other static maps: s_glExtensionSetList, > s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions > object, we will get the answers from last time, because they were cached. > > It seems to me that if we need to store these per context ID, and if we can > re-use context IDs, then we need a way to clear out what is stored, possibly > when the context ID usage count goes to 0, or maybe explicitly. > > thanks > > andy > > -----Original Message----- > From: osg-users <[email protected]> On Behalf > Of Robert Osfield > Sent: Wednesday, September 19, 2018 4:20 AM > To: OpenSceneGraph Users <[email protected]> > Subject: Re: [osg-users] context IDs > > Hi Andy, > > It's quite a while since I worked specifically on the osg::State, > ContextID, osg::GLExtensions management. In principle it should be > possible to reuse ContextID's, the sticky issue of whether the > GLExtensions object is recreated for each new graphics context is > something I haven't personally tested. Looking at osg::State is does > look to clean up the GLExtensions object in 3.4 onwards (I haven't > checked further back) > > For graphics performance I would recommend that applications don't go > creating and destroying GraphicsWindows, if possible just hide the window and > reuse it will provide better performance. > > Cheers, > Robert. > On Mon, 17 Sep 2018 at 19:08, Andy Skinner <[email protected]> wrote: > > > > If we get our contextIDs from GraphicsContext::createNewContextID(), it > > could give us a new number or return a previous one, if we are returning > > them with GraphicsContext::decrementContextIDUsageCount. Right? > > > > > > > > Is there an intended connection between a contextID that has been used and > > a new one? It looks to me that extensions are stored per context ID and > > never reset. > > > > > > > > So if we change something about what we are looking for in the context > > (sometimes we fall back to software OpenGL for testing or helping a > > customer through an issue), we might reuse a context ID, but still have > > extensions associated with the ID that are not appropriate for it. > > > > > > > > Am I missing an assumption here? Should I be able to reuse a contextID for > > an unrelated context? If not, I'll just remove call to > > decrementContextIDUsageCount. That means the number and various maps will > > continue to grow. > > > > > > > > thanks > > > > andy > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > > openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
