Here's what I'm thinking of....sorry for the huge commit
ChangeLog (in absence of commit history)
introduce a TextureGraphicObject ( buffered_object PCTOs -arg why can't I
rename Texture::TextureObject to Texture::GLTextureObject, TextureGraphicObject
is a so ugly name?!! - )
inject a base class for PerContextGraphicObject (base of BufferObject,
TextureGraphicObject (bufferedPCTOs), ProgramsObject ..)[/list]
deprecate Image less Texture by adding an Image with NULL data (may require
further data==0 tests to ensure retrocomp) and make unrefimageafterapply just
remove buffered_object from Texture to use the TextureGraphicObject of its
I'll try to clean the PR if community is everyone happy with it
> I have reverted the PR, this resolved the osgcomputeshaders bug.
> On 2 February 2018 at 09:17, Robert Osfield <> wrote:
> > On 1 February 2018 at 20:46, Julien Valentin <> wrote:
> > > The bufferobject is null because of the design used for
> > > unRefImageDataAfterApply feature
> > > Texture owns textureobjects in order to deref bufferdata
> > >
> > > What I propose/ask to Robert is to release only data of the Image data
> > > keeping the chain Texture->BufferData(Image)->BufferObject(a new
> > > classTextureObject)->GraphicObject intact
> > >
> > Umm.... lets change something that's been working fine for well over a
> > decade to fix an issue recently introduce by an ill-considered
> > submission.
> > I will need to look deeper into the issue and decide what is best to
> > do. I don't have the time to do this right away. Might have time
> > next week.
> > Robert.
> osg-users mailing list
> Post generated by Mail2Forum
Read this topic online here:
osg-users mailing list