Hi Ulrich,
The updating of a texture's images happen before the image's modified-count is
updated by the dirtying thread. This means that even if a third thread updates
the image in the mean-time, this new update doesn't get missed from being
uploaded to VRAM as the texture-upload happens
Hi Anish,
Looking at the fix I don't think this works in all cases, it only makes it less
likely to
occur.
The check and the set are still done non-atomically, so another thread could be
scheduled
inbetween and one update would be lost.
My preferred solution would be to use std::atomic with
H Anish,
Thanks for the fixes, I've merged them with the OpenSceneGraph-3.2 branch
and then applied similar changes to OpenSceneGraph-3.4 branch and master, I
couldn't apply the changes directly to these as the code base has changed a
little too much to make a direct merge easy.
Could you test
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" wrote:
> Hi Robert,
>
> I can submit a fix then.
> Thanks for the quick reply.
>
> Cheers,
> Anish
>
>
> robertosfield
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
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