20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
→Context sharing
| Line 651: | Line 651: | ||
automatically assign the same ContextID for each of the seperate | automatically assign the same ContextID for each of the seperate | ||
osg::State objects.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg02505.html</ref> | osg::State objects.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg02505.html</ref> | ||
The scene graph is shared between the two slave Cameras. If | |||
the slave Camera have different graphics contexts then you can have | |||
separate OpenGL objects per context, but the OSG will automatically | |||
manage this all for you, it also offers the opportunity for threading | |||
the graphics contexts.<ref>https://groups.google.com/g/osg-users/c/4PECSribbLQ/m/niZFUC4Hnn0J</ref> | |||
* It's possible to share contexts in the OSG [...] As for general desirability of share GL objects between contexts, yes it can reduce memory usage, but it forces you to use the OSG single threaded otherwise two contexts will be contended for the same resources that deliberately aren't mutex locked for performance reasons. There is also on a limited set of cases where drivers/hardware will actually share OpenGL contexts. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32676.html</ref> | * It's possible to share contexts in the OSG [...] As for general desirability of share GL objects between contexts, yes it can reduce memory usage, but it forces you to use the OSG single threaded otherwise two contexts will be contended for the same resources that deliberately aren't mutex locked for performance reasons. There is also on a limited set of cases where drivers/hardware will actually share OpenGL contexts. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32676.html</ref> | ||