This could apply to a problem I have been having in my own application.
Please post your fix once you have it.
On Oct 17, 2017 5:01 AM, "Anish Thomas" <thomas.an...@gmail.com> wrote:
> Hi Robert,
>
> I can submit a fix then.
> Thanks for the quick reply.
>
> Cheers,
> Anish
>
>
> robertosfield wrote:
> > Hi Anish,
> >
> >
> >
> > I think you are correct, the way to handle concurrrent reading/updates
> of an osg::Image is to take a local copy of the
> osg::Image::getModifedCount() prior to reading from the image and then use
> this value. This would still have the danger of the image data being
> updated at the same time as it's being read but at least a texture update
> wouldn't be missed.
> >
> >
> > Robert.
> >
> >
> >
> > On 17 October 2017 at 09:38, Anish Thomas < ()> wrote:
> >
> > > Hi,
> > >
> > > While modifying texture-atlases in DBPager threads we noticed an issue
> of thread-synchronization.
> > >
> > > Code like the snippet below (From Texture2D.cpp):
> > >
> > > else if (_image.valid() && getModifiedCount(contextID) !=
> _image->getModifiedCount())
> > > {
> > > applyTexImage2D_subload(state,GL_TEXTURE_2D,_image.get(),
> > > _textureWidth, _textureHeight,
> _internalFormat, _numMipmapLevels);
> > >
> > > // update the modified tag to show that it is up to date.
> > > getModifiedCount(contextID) = _image->getModifiedCount();
> > >
> > > }
> > >
> > > If another thread (like a DBPager thread) modifies the image of a
> texture (in this case a texture-atlas which gets more and more images added
> to it while it is also being applied on geometry), the modified count
> changes made by one or more dirty() calls can get missed.
> > >
> > > If the image got dirtied before the RenderThread tried to apply this
> texture, code-execution enters the if() described above. If the texture
> upload takes too long and the image is dirtied again, the effect of the 2nd
> dirty can be missed when the modified count of the image is put into the
> texture.
> > >
> > > A simple solution would be to use a local variable to store the
> image's modified-count, and apply it to the texture. The overhead of a
> possible redundant texture-upload on the next apply would be down-side. But
> texture-atlases would support multi-threaded updates better.
> > >
> > > Thoughts?
> > >
> > > Thank you!
> > >
> > > Cheers,
> > > Anish
> > >
> > > ------------------
> > > Read this topic online here:
> > > http://forum.openscenegraph.org/viewtopic.php?p=72188#72188 (
> http://forum.openscenegraph.org/viewtopic.php?p=72188#72188)
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > osg-submissions mailing list
> > > ()
> > > http://lists.openscenegraph.org/listinfo.cgi/osg-
> submissions-openscenegraph.org (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=72191#72191
>
>
>
>
>
> _______________________________________________
> osg-submissions mailing list
> osg-submissions@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-
> submissions-openscenegraph.org
>
_______________________________________________
osg-submissions mailing list
osg-submissions@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
