On 10/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
On Tue, 2006-10-03 at 21:28 +0100, Robert Osfield wrote:
> Or do we create another subclass from osg::Obejct something like
> ObjectWithPotentailOpenGLObjectThatMightNeedReleasing...
Yes I agree (thanks to the discussion up to this point). Extending the
mix-in design of osg::Object leads nicely to a clean derivation (pseudo
code) that encapsulates GL resource management:
class osg::GLObject : public virtual osg::Object {
virtual void releaseGLObjects(osg::State* = 0) const {}
};
... for other classes to mix-in instead of osg::Object directly.
Well GLObject is a bad name, as its not actually a GLObject but a data structure that potentially can hold
a GL object or GL objects, or a graph or objects that may contain one of more objects...
One really has to balance base class complexity against the number of seperate base classes, its really down to a matter of good taste and praticality. I general I have to agree fat base classes are not appropriate, but sometimes its the most expedient thing to do.
In this case osg::Obect::releaseGLObjects(osg::State*) is probably not too bad a compromise.
Robert.
Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
