Hi, On Thu, 2010-06-03 at 09:44 -0500, Carsten Neumann wrote: > Hello Gerrit, > > Gerrit Voß wrote: > > On Wed, 2010-06-02 at 12:17 -0500, Carsten Neumann wrote: > >> Aron Bierbaum wrote: > >>> We have been running into what appears to be a corner case in the > >>> ShaderProgram. As most of you probably know each OpenSG object that > >>> needs to track a GL object ID registers it's OpenGL creation and > >>> destruction functors through Window::registerGLObject(). This > >>> registration returns a unique OpenSG ID for each registered object. > >>> This unique OSG is then used in each objects handleGL() and > >>> handleDestroy() methods to get the context specific OpenGL object ID > >>> from each window. (ex: win->getGLObjectId(getGLId())) The normal > >>> operation is that when an object is created for a window you call the > >>> OpenGL function and set the OpenGL object ID in the ID map. Then in > >>> handleDestroyGL() you clear this ID mapping by setting it back to > >>> zero. > > > > not quite, the reset should have happened from where the destroyed > > functor is called but it seems in the wrong place. I would prefer > > to have it there instead of pushing the responsibility to every > > class that uses the gl id infrastructure. > > hm, ok, that would prevent this kind of problem in the future. > > >>> Although I think that we should fix these locations so that the IDs > >>> are rest correctly, can the ShaderProgram code be changed to not have > >>> such a fragile requirement for checking the OpenGL ID against zero. I > >>> have attached a patch for an older revision of OpenSG 2.0 that relaxes > >>> this requirement and we have been using for a few weeks without any > >>> issues. > >> I've also committed a patch similar to the one you sent, but made > >> surrounded the test with #ifdef OSG_DEBUG. > >> If indeed ShaderProgram can test the mode instead of the gl id, this can > >> be removed again. > >> Thanks again for the bug analysis and patch! > > > > to understand it better, how many windows are in your environment ? > > > > In general something looks not quite right in the whole gl object > > handling inside the window so I will have a further look. > > quite possible, it is a bit complicated ;) However, I think the only > problem is that the _id array entry are not set to zero when the > corresponding _glObject array entry is set to NULL in doFrameExit(). > Window::registerGLOject() only looks into _glObject to determine what > ids are available.
hmm, there is/was a this->setGLObjectId(i+j, 0); in there but IMHO to late as the _ids array is a window local array, so with multiple windows only the last window should have the ids set to 0. But the example uses only 1 window so there seem to be another way around it. I'm still hunting for this, one suspect is the early out in destroyGLObject in case of parallel drawers. I'm still building a test setup ;) > hm, thinking about this, I'm not even sure we really need to set unused > ids to zero (except to ease debugging perhaps). ShaderProgram should > probably just not use id 0 to mean the same as mode == initialize? from looking at it, it was probably just laziness on my side as the initial if already contained initialize I did not bother to check again. I don't see a reason why we can change to check the mode. I'll change it and observe it for a while. kind regards gerrit ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
