Hi Lionel, Using a count is more complicated for sure, but as it's more robust worth looking to. It might be the the complexity isn't worth the extra effort in which case the fallback position is going with your solution with just tweaking the names.
On 30 May 2013 13:48, Lionel Lagarde <[email protected]> wrote: > The counter cannot replace the hasBeenRead member of BufferEntry. They are > created lazily > during the texture application or compilation. The number of "users" is > unknown at this time. > > The counter cannot be placed inside BufferObject because the > IncrementalCompileOperation is unable to know the number of textures > referencing the processed image while it is setting up the PBO. > > The counter can be placed inside BufferData. The texture can keep it up > (inside setImage, the constructor and the destructor). > > The counter should be made contextual. Texture::setImage should increment > the counter > of all the contexts and Texture::apply should decrement only the counter of > current > context. > > The counter looks like a contextual version of the texture ref_ptr on the > image. Is there any change the osg::Texture support for UnRefImageDataAfterApply facility might be usable here? Once the image has been applied the texture just sets the _image ptr to 0, which would in turn call BufferObject::removeBufferData() and the last Image to be deleted would set the BufferObject to 0 and release it. Any chance this would work fine your case? Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
