would trigger unnecessary redraws when there were pending file requests or active database threads
tested ok with and without IncrementalCompileOperation
Incorrect values read from a different memory region will cause incorrect computations. In osgDB::base64_decode_value(char): Out-of-bounds read from a buffer
Objects with the same filename may be different from others based on the provided
plugin options. Using filename *and* the provided options as object cache key
helps to avoid fetching the wrong object.
forcing users to use osgDB::readRef*File() methods. The later is preferable as it closes a potential threading bug when using paging databases in conjunction
with the osgDB::Registry Object Cache. This threading bug occurs when one thread gets an object from the Cache via an osgDB::read*File() call where only
a pointer to the object is passed back, so taking a reference to the object is delayed till it gets reassigned to a ref_ptr<>, but at the same time another
thread calls a flush of the Object Cache deleting this object as it's referenceCount is now zero. Using osgDB::readREf*File() makes sure the a ref_ptr<> is
passed back and the referenceCount never goes to zero.
To ensure the OSG builds when OSG_PROVIDE_READFILE is to OFF the many cases of osgDB::read*File() usage had to be replaced with a ref_ptr<> osgDB::readRef*File()
usage. The avoid this change causing lots of other client code to be rewritten to handle the use of ref_ptr<> in place of C pointer I introduced a serious of
templte methods in various class to adapt ref_ptr<> to the underly C pointer to be passed to old OSG API's, example of this is found in include/osg/Group:
bool addChild(Node* child); // old method which can only be used with a Node*
tempalte<class T> bool addChild(const osg::ref_ptr<T>& child) { return addChild(child.get()); } // adapter template method
These changes together cover 149 modified files, so it's a large submission. This extent of changes are warrent to make use of the Object Cache
and multi-threaded loaded more robust.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15164 16af8721-9629-0410-8352-f15c8da7e697
a way that when CMAKE_INSTALL_PREFIX contains something along the lines
of
/usr/x86_64-linux-gnu/
it gets substituted as
/usr/x86_64-1-gnu/
that is, the string is preprocessed again, thereby making changes to
anything that matches any defined symbol, as "linux" in this example
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763816).
Quoting that path directly in CMake scripts solves that problem.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14522 16af8721-9629-0410-8352-f15c8da7e697
The problem is that the readObjectFields method will add the object to the _identifierMap. So all the other instances of that image in the same file will be replaced by the created dummy object. In my fix this was an dummy image and I didn't notice it in our scene's, probably because it covered a small part of an object. In your fix the dummy object was not an image and that leads to a crash when something tries to use it as an image. I have attached a small fix for this bug.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14471 16af8721-9629-0410-8352-f15c8da7e697
