Hi Jose, The OSG's is written to handling multi-theading of shared contexts as handling this special case would require us to add lots of mutex locks to all OpenGL code that is setting or using OpenGL objects.
It's better to avoid shared contexts. Robert. On 24 September 2013 06:34, Jose Ignacio Anguita <[email protected]> wrote: > Hi, > > I'm currently using OSG 3.0.1 > > I'm having a problem with the Database Pager when i use the > IncrementalCompileOperation with a shared context. > > I'm trying to compile the GL objects in a separate thread. DatabasePager run > in the main thread and send operations to the incremental compiler that is > running in a different thread with a shared context. Everything seems to work > fine, but eventually I can get these messages: > > GLBufferObjectSet::checkConsistency(): Error..... > Texture::TextureObjectSet::checkConsistency(): Error .... > > when this happens, you can see some texture with bad data or random geometry > in the scene. However, there are no errors GL. > > One test has been to eliminate in the incremental compiler any compile > operation, passing this to run on the main thread first painted. This all > works fine but I'm not compiling on a different thread so the performance > loss falls on the main thread. > > I think the problem is that the two threads share the managers and is not > thread safe. Can this be possible? > > if so, how I can set up a system to compile GL objects in a shared context? > > Thank you! > > Best, > Jose Ignacio > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=56447#56447 > > > > > > _______________________________________________ > 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
