Multiple render actions may be passed to an effect at the same time. A plug-in states it's level of render thread safety by setting the
string property. This can be set to one of three states....
kOfxImageEffectRenderUnsafe- indicating that only a single 'render' action can be made at any time amoung all instances,
kOfxImageEffectRenderInstanceSafe- indicating that any instance can have a single 'render' action at any one time,
kOfxImageEffectRenderFullySafe- indicating that any instance of a plugin can have multiple renders running simultaneously
When rendering on computers that have more that once CPU (or this new-fangled hyperthreading), hosts and effects will want to take advantage of all that extra CPU goodness to speed up rendering. This means multi-threading of the render function in some way.
If the plugin has set
, the host may choose to render a single frame across multiple CPUs by having each CPU render a different window. However, the plugin may wish to remain in charge of multithreading a single frame. The plugin set property
informs the host as to whether the host should perform SMP on the effect. It can be set to either...
A host may have a render farm of computers. Depending exactly how the host works with it's render farm, it may have multiple copies on an instance spread over the farm rendering separate frame ranges, 1-100 on station A, 101 to 200 on station B and so on...
Some plugins need the output of the previous frame to render the next, typically they cache some information about the last render and use that somehow on the next frame. Some temporally averaging degraining algorithms work that way. Such effects cannot render correctly unless they are strictly rendered in order, from first to last frame, on a single instance.
Other plugins are able to render correctly when called in an arbitrary frame order, but render much more efficiently if rendered in order. For example a particle system which mantains the state of the particle system in an instance would simply increment the simulation by a frame if rendering in-order, but would need to restart the particle system from scratch if the frame jumped backwards.
Most plug-ins do not have any sequential dependence. For example, a simple gain operation has no dependence on the previous frame.
Similarly, host applications, due to their architectures, may or may not be able to guarantee that a plugin can be rendered strictly in-order. Node based applications typically have much more difficulty in guaranteeing such behaviour.
To indicate whether a plugin needs to be rendered in a strictly sequential order, and to indicate whether a host supports such behaviour we have a property,
. For plug-ins this can be one of three values...
For hosts, this property takes three values...
When rendering, a host will set the in args property on
to indicate whether the host is currently supporting sequential renders. This will be passed to the following actions,
Hosts may still render sequential effects with random frame access in interactive sessions, for example when the user scrubs the current frame on the timeline and the host asks an effect to render a preview frame. In such cases, the plugin can detect that the instance is being interactively manipulated via the
property and hack an approximation together for UI purposes. If eventually rendering the sequence, the host
ignore all frames rendered out of order and not cache them for use in the final result.
A host may set the in args property
the sequence render action
to asj for a render in Draft/Preview mode. This is useful for applications that must support fast scrubbing. These allow a plug-in to take short-cuts for improved performance when the situation allows and it makes sense, for example to generate thumbnails with effects applied. For example switch to a cheaper interpolation type or rendering mode. A plugin should expect frames rendered in this manner that will not be stucked in host cache unless the cache is only used in the same draft situations.