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.
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?
For avoidance of doubt, I'll not make further changes until I hear back
from you.
Cheers,
Carsten
------------------------------------------------------------------------------
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
