robertosfield wrote: > > Hi Julian, > > I have just reviewed the changes but get the sense that > TextureBuffer/BufferObject classes are being stretched in different > directions. > > The approach you have taken assumes that BufferObject "owns" a list of > BufferData, whereas the way the OSG currently manages things is that > the BufferData (osg::Image, osg::Array) "own" their BufferObject, and > the BufferObject just hold a C pointer back to their parent which is > the BufferData. > > The approach you are taking breaks this and will either result in > memory leaks and dangling pointers of force BufferObject to take a > ref_ptr<> to keep the BufferData around, which then will lead to a > circular reference and associated memory leak. >
Are you sure about circular reference and memory leak...? Is ref_ptr not built in order to adress such issue?.. This would be great that BufferObject would store refpointed BufferData. It would allow to let user choose with which he wanna play with (BufferData or BufferObject) (As far as I know the only place where bufferData are released is in UnrefImageAfterApply textureXD management) Further I tested it (use ref_ptr <BufferData> in BufferObject) and didn't see any problem in the use cases I have checked ( I even put circular ref in BufferData BufferObject serializers and it seams to works great) robertosfield wrote: > > The replacement of ModifiedCount with a DirtyFlag also breaks the > naming convention and function. The ModifiedCount is used as multiple > contexts can download GL data at different times, here if you store > the ModifiedCount at download for each context then you can then make > sure that all contexts GL objects will be properly updated, something > that can't be done with a DirtyFlag that gets set to true and then > back to false as soon as the first context downloads the data. > > DirtyFlags are per context so I don't think you're right: theyre all set to true when bufferobject changes and reset to false in the percontext draw. Further i renamed ModifiedCount DirtyFlags just because I didn't want to breaks any implicit naming conventions. robertosfield wrote: > > I think I now understand what functionality you are after i.e. to > enable TextureBuffer to be used directly with a BufferObject (and > hence associated GLBufferObjects) without the need for an osg::Image > to assign it to. I'm not the author of TextureBuffer so can't comment > directly why the author decided to force the use of an osg::Image. > > Looking at the git log for TextureBuffer the first commit is: > > commit 1284a0dd40051738f7073afdd41667d960631f8b > Author: Robert Osfield <> > Date: Wed May 22 12:49:46 2013 +0000 > > From Pawel Ksiezopolski, first email: "This submission adds > texture buffer object ( defined in GL_ARB_texture_buffer_object > extension ) to the osg::Texture* family. > > TextureBuffer objects may use osg::Texture::bindToImageUnit(), so > GLSL shaders are able to use not only texelFetch() function , but also > functions defined in GL_ARB_shader_image_load_store extension : > imageLoad(), imageStore(), imageAtomicAdd() etc." > > second email: "After a while I found that > osg::Texture::applyTexParameters() used with TextureBuffer may cause > some OpenGL errors ( applying texture filters and wraps to > TextureBuffer makes no sense ) so I fixed it." > > The TextureBuffer also looks to be used in the osggpucull and > osgforest examples. > > I haven't yet looked into these examples to see the exact usage of > TextureBuffer and how it might be affected. I did wonder if > TextureBuffer could be modified to allow a BufferObject to be assigned > directly and the osg::Image dependency removed completely. Or perhaps > just allow the osg::Image to be NULL if a BufferObject has been > directly assigned. Another approach is to have a TextureBufferImage > as well as TextureBuffer class. > > Robert. > > > On 5 June 2016 at 22:35, Julien Valentin <> wrote: > > > Hi, > > Here's a version of TextureBuffer that seams clean to me.. > > Its main interest is to bind any BufferObject to TextureBuffer: > > It allows (for example) to bind TransformFeedBack generated Buffer as TBO > > for Instancing purpose. > > Waiting critisms and sugsestions > > > > Cheers, > > Julien > > > > ------------------ > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=67425#67425 > > > > > > > > > > _______________________________________________ > > osg-submissions mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > ------------------ > Post generated by Mail2Forum ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67451#67451 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
