Hi, On Thu, 2010-06-03 at 09:34 -0500, Aron Bierbaum wrote: > On Thu, Jun 3, 2010 at 2:31 AM, Gerrit Voß <vo...@vossg.org> wrote: > > > > Hi, > > > > On Wed, 2010-06-02 at 12:17 -0500, Carsten Neumann wrote: > >> Hello Aron, > >> > >> 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. > > I would agree if the location that invokes the destroy GL functor has > enough information to reset the ID, then it would be a lot more robust > for this reset to happen in a single location.
IMHO it has, there was already code in there to reset the gl id to 0, just in the wrong place (that's why I asked about the number of windows). Anyway if we call the destroy functor with the expectation and information to reset the gl id we should be able to do it from the calling location without problem ;) > > > > 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. > > > > kind regards > > gerrit > > We are actually only using a single passive window inside of Qt. I > believe that we are running into this because we are dynamically > creating and destroying a lot of geometry and textures. Our > application is based on a globe, so we start by zooming into a city. > This causes geometry and textures to be paged into and out of the > system. Once at a city view if we add and remove geometry with a > shader attached we will see this problem occur. hmm, one window, ok second try, multiple threads ? I'm still trying to understand the underlying problem to its full extend. 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
