Modifying images during a draw

Generally speaking, REDsdk does not allow any image modification during a draw. This covers both hardware rendering and software rendering. While a rendering occurs, the local storage of an image is the only data that can be freely manipulated. All other operations are restricted.

That's why we describe that images can be loaded from .red files while a GPU rendering occurs, assuming that the RED::StreamingPolicy::SetLocalImages policy is turned on.

Any object that is using RED::State transactions has two storages: one for its current definition and one for its former definition. This can consume memory when the object is being modified, but this offers a very interesting flexibility to the application design, allowing modification of data while rendering.

Images do not have duplicate storages. Images are directly loaded on the GPU if REDsdk runs in hardware mode, and, in order to save memory, REDsdk does not keep any copy of the image. Furthermore, the contents of an image may result of a rendering operation. Therefore we hardly can allow an application to modify an image at the same time it's being defined.

So, image operations are always synchronous. They do use the RED::State parameter in their API to clearly identify writing methods from reading methods, but the operations are performed synchronously at the time of the call. Consequently, many methods will return a RED_WORKFLOW_ERROR if they're called in parallel to the rendering of a frame.