Standard version: 1.5
(sept 23, 2016) - this is to be simultaneously addressed with caching and multi-processing.
Currently only one kind of plug-in instance is recognised, this is used for everything, interface, caching state, rendering etc… Many host applications have severe problems with this model, as they typically have separate render objects that are either lightweight special purpose render objects, or cloned on demand copies of the effect.
To deal with the current API, they either have multiple instances of a plug-in around, continually syncing data from the persistant/UI version to the render version, or they do this on demand. This often leads to sub-optimal performance and a great deal of complexity.
Plug-ins also find this difficult, as they often cache data in an instance, expecting to be able to re-use that data on the next render (eg: motion vectors from a retimer). In a clone on demand host, as the instance is continually being re-created, this cached data is always being destroyed once the temporary render instance is released.
A good way to manage this would be to have the API support a special purpose lightweight render instance object. The full effect instance is asked to populate one of these with any data it needs for the render action (and related actions such as RoD/RoI?), this object is then called to do the actual pixel pushing. This decouples object persistence and interface from processing, and allows for better multi threaded behaviour.
This is a major and complex change to the API and needs to be thoroughly discussed between host devs and plug-in devs.
As plug-ins are currently caching data between renders within the persistent instance (as in our retimer example), we still need to allow a plug-in to cache data in some manner. A better way all round would be for an explicit caching API, which a render object or persistent object could both commit and retrieve data to a host managed cache in a thread safe manner.