On 28.05.2015 15:57, Robert Osfield wrote:
Hi Jannik,
I have merged your first set of changes to BufferObject, but not the
ones to Texture related calls. The later have a cache of
ref_ptr<TextureObject> that remains in scope during the
Texture::apply() methods so there shouldn't be the same issue with
BufferObjects getting deleted. If you have a specific case that shows
a problem with TextureObject management let me know and I can look at
it. Want I want to avoid is unneccesary ref()/unref()'s happening on
TextureObjects on every Texture::apply() like you had.
Hi Robert,
I did see that the texture's apply has a ref_ptr<TextureObject> cache
(the _textureObjectBuffer[contextID], right?).
Sorry for not explaining earlier, my reasoning for that change was as
follows.
There is still a bug though on this line:
_textureObjectBuffer[contextID] = textureObject =
generateTextureObject(this, contextID, GL_TEXTURE_1D);
The generated texture object is first assigned to textureObject (a
TextureObject* raw pointer), and only then the result of that assignment
to _textureObjectBuffer. That means, there is a point where no ref is
held, and same crash as with VertexBufferObject could occur (although
astronomically unlikely).
To fix this problem, the order of assignments might be reversed:
textureObject = _textureObjectBuffer[contextID] =
generateTextureObject(this, contextID, GL_TEXTURE_1D);
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?
Thanks,
Jannik
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
