robertosfield wrote: > > In the case when the image is shared it looks to me like the best approach > would be to not allow any additional modifications to the image by the > InputStream::readImage() method. Even if you added mutex locks around the > write operations to the mutex you'd ended with an image that flips state > during it's lifetime so that the original owners of the image would then have > an Image in a new state that it doesn't have baring on what it was > originally. This might be OK in some instances, but could cause real > problems for application/code that assumes the Image is invariant once it has > been set up. > > Changing the behaviour to ignore the local modifications when an Image is > shared is something that might break applications too, but my instinct is to > treat Image as invariant once setup is the more common case so will affect > users left often than the current state. Perhaps one possibility would be to > have a flag in InputStream to give a hint to what to do. > > > > If we do ignore the extra write for Image's pulled from the cache we'd need > to still read then discard the options to avoid breaking file compatibility. > > > > Another, more drastic workaround would be to duplicate the osg::Image from > the cache and let the new Image be modified. This rather defaults the > purpose of using a cache though. > > > It's worth adding that this cached object issue will be a wider one that just > Image handling, so whatever solution we plump for we'll need to tackle these > other cases as well. >
I'm with you on not changing an image (or other objects) state when it's already in a cache. If people don't want this they should turn the cache off or clear the cache or clone things in the cache or whatever they need. OSG has options for that. Right now I made a small modification on my side to osg that (in case the image comes from a cache) makes a dummy image and uses that one to read too. Then discards that image. For the scenes we work with that works but as you said this issue could be wider that only the images. An option in the InputStream and Serializer class to not set any data to an object, or even better to skip parsing the data (but for the latter you would need an end offset for binary files) would be great. It would allow to easily solve these issues when they come up and could potentially be used to do more advanced things later on. ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61430#61430 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
