[osg-submissions] Reuse of context IDs and cleanup of OpenGL resources.

[Mark Sciabica]

Hi Robert,

I like the idea of moving resource management out of the objects. Having 
it all in one place will make for more uniform and maintainable code, 
and removing the mutable members from objects will be especially nice. 
But I do see a couple potential problems that I'd like to make sure 
you're aware of before implementing a new design.

1. If two contexts share a contextID, their states need to share 
resource management.

2. If resource management is moved to the state object it will be more 
difficult for end users to add support for new OpenGL extensions that 
require resource allocation. With the current design they only need to 
create a single custom attribute that implements its own creation, 
application, and deletion of any new resource. Moving resource 
management to the state will require some hooks for user code either 
through callbacks or overridable virtual functions if you want to 
maintain the ability of end users to use new features requiring resource 
management without modifying core osg.

Mark

Robert Osfield wrote:
> Hi Mark and Mathias,
>
> Thanks for the extra explanation, its useful to get an insight on
> where things are failing.
>
> On Wed, Apr 16, 2008 at 7:35 AM, Mathias Fröhlich
> <M.Froehlich at science-computing.de> wrote:
>   
>>  Wouldn't it be better to stick such objects and cached information into the
>>  GraphicsContext class? Then they get deleted, once they are no longer
>>  valid ...
>>     
>
> One design change I have been considering for a couple of years is to
> move GL object ID management from the local StateAttribute/Drawable
> classes into osg::State.  Extensions being per context could also get
> the same treatment.  It would require us maintain a unique ID per
> StateAttribute/Drawable, which is used as look up to the GL objectID.
>
> The reason to put it into osg::State rather than GraphicsContext is
> that now all apps use osgViewer, and osg::State purpose is to track
> OpenGL state so conceptually its the right place, and finally all the
> apply()/draw() methods get pretty direct access to osg::State via the
> RenderInfo structure.
>
> This new design would solve the issues of deleting contexts, as one
> would delete the osg::State object for the context, and there would be
> no need to go cleaning the scene graph as there is no actual OpenGL
> obejcts in the scene graph itself, just a ID which stays constant for
> the life of the object.
>
> Given how close 2.4 is, its not possible to put such sweeping changes
> in.  I believe above design is the right way to tackle this  problem
> (as well as others), and also believe that merging extra workaround
> code for the limitations of the current design would just complicate
> the existing code and make it even more awkward to maintain.
>
> I will tackle the above design change in the 2.6 round.  I'd expect
> it'd be about a weeks work.
>
> Robert.
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20080416/037fbb08/attachment.htm