On 11 November 2014 10:50, Robert Osfield <[email protected]> wrote:
> > Perhaps placing a small cache object map into the osgDB::Options structure > would be appropriate, this way loaders can query either the locally > assembled one or the main one in the osgDB::Registry. > > It all could get quite sticky if we aren't careful though. I will > continue thinking about the topic. > My current inclination is create a new class osgDB::ObjectCache and have this manage a local std::map<filename, object>, have osgDB::Registry "have a" ObjectCache, and also let osgDB::Options have a local ObjectCache ref_ptr<> to manage a local user supplied cache that can be read/written to in preference. If a local ObjectCache is present then the Registry ObjectCache would would only be possible to read from, while the local ObjectCache it'd be possible to read and write to. osgDB::Registry::readImplementation() could handle the differences between the Regisytry and the Options ObjectCache, so loaders wouldn't need to worry about it unless they specifically wanted to handle it. For the osgDB::DatabasePager it'd have an empty ObjectCache assigned to the local Options for each read and would copy any entries into the main Regisytr::ObjectCache during the merge with main scene graph operation. Thoughts? Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
