Hi Robert, >> The questions is how to do this.... The easist way might be to have a >> singleton tracking all the Extension objects for each context so we >> have a single entry point in destructing all of the ones for a >> particular context.
That would be the preferred solution IMO since it would remove the need to track in the GraphicsContext::close() implementation all the places in OSG where extension use context-specific information and replace that with a single call. >> Another issue lurking is that current ContextID's are the same for >> contexts that are shared, and since the Extension objects also use the >> ContextID to get the approrpiate one for that context it also forces >> the assumption that not only are OpenGL objects shared, but function >> pointers too. Do you know if this is a safe assumption? I still have my homeworks to do on shared contexts (never used them before; need to understand their pros and cons), but from the understanding I have of them I'm afraid this would not be a safe assumption for a system hosting differing hardware implementations (let's say a NVIDIA and AMD-ATI graphics board, and trying to share a context across). I would assume however this is safe when all graphics cards have the same driver. André -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Robert Osfield Envoyé : January 25, 2007 12:10 PM À : osg users Objet : Re: [osg-users] Reusing a previously freed context ID Hi André, The Node::releaseGLObjects(State*) is responsible for cleaning all OpenGL objects associated with a graphics context, and osg::GraphicsContext is now implemented to call this on all the Camera's associated with it. On destruction the ContextID's are also cleaned up. This clean up operation should allow one to create windows on demand, including reuse of ContextID's. I did testing with repeatedly create and destructing viewers and associated windows and it did work solidly under X11, but... In the your email your mention about per context Extension objects and this sends alarm bells off for me as currently there is no mechanism for destruction the Extension objects and recreating them. Under all platforms except Windows the function pointers doing change when you change delete and recreate graphics context, but under Windows each context has a separate function pointer, even though its really just the same function so.... we'll need to force the destruction of the Extension objects too. The questions is how to do this.... The easist way might be to have a singleton tracking all the Extension objects for each context so we have a single entry point in destructing all of the ones for a particular context. Another issue lurking is that current ContextID's are the same for contexts that are shared, and since the Extension objects also use the ContextID to get the approrpiate one for that context it also forces the assumption that not only are OpenGL objects shared, but function pointers too. Do you know if this is a safe assumption? Robert. On 1/25/07, André Garneau <[EMAIL PROTECTED]> wrote: > Hi Robert, > > I've been investigating the reasons windows moved from one screen (i.e. > display adapter) to another do not render properly (on the Win32 platform) > and came to the conclusion that under Windows we basically need to rebuild > the window completely from scratch when it is moved to a new display adapter > (because we need to change its pixel format relative to the new target > adapter and in Windows you cannot change the pixel format more than once). > > My current idea for targeting this is to close and re-initialize the > graphics context to have it setup properly for the new display adapter since > such things as GL extensions, display lists, etc. need to be rebuilt as > well. > > Looking at the code, I'm realizing that this may involve more work on the > core OSG side, since not everything related to a given context ID seem to be > cleaned up when it is freed (for example GL Extensions for the old context > ID seem to be retained, display lists in drawables also, textures, etc.) > > This leads me to believe that the current code does not (for the moment) > support the dynamic reuse of a previously access context ID; it will > reallocate it but will not cleanup the previous information it held > completely. > > Am I right on this or is there some code that will take care of disposing > all such data when a contextID is freed ? > > André > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
