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
