Hi Robert,
On 28.05.2015 16:29, Robert Osfield wrote:
This wouldn't fix the bug unless we include the change of
generateTexturteObject to return a ref_ptr<>.
Indeed. I didn't know if you had applied that already. I don't see any
new commit in the svn log yet, so I can't tell. Perhaps the push was
forgotten?
However, I felt that the for the order of assignments to have a semantic
meaning was not right. Therefore I went for the safer alternative of having
textureObject become a ref_ptr.
I see your point though about overheads within apply(), since it's called on
every frame. What do you think?
Keep on doing a ref/unref there isn't strictly required is something
we need to avoid, if there is a fix that doesn't create this overhead
then we should pursue it.
The re-ordering suggestion achieves the aim of fixing the bug and
avoiding the overhead, but it's so subtle I'd rather look for a more
explict mechanism. First step is changing generateTextureObject(..)
so it returns a ref_ptr<TextureObject>, then the next step would to
result the
textureObject = _textureObjectBuffer[contextID] =
generateTextureObject(this, contextID, ..)
My inclination would be the create a new method
generateAndAssignTextureObject(...) that calls the
TextureObjectManage::generateTextureObject(..) to create the
TextureObject, assigns it to the local _textureObjectBuffer[contextID]
and then returns a TextureObject* to this assigned TextureObject. The
Texture*::apply() methods would then be ported across to the new
method.
Thoughts?
Sounds good to me. My guess is that new function should be inlined and
in the osg::Texture base class.
I will work on another patch.
We'd also need a .get()
in case the OSG is built without automatic pointer conversion.
Good point, I'll make sure to test that switch.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
