Standard version: 2.0
Major Change
Private data is parameter data a plugin keeps in its own data structures. These are for large or complex data types that can't be represented with the current parameter set. For example a custom roto-spline parameter. For persistance, and possibly animation, private data needs to be synced back into a plugin's actual parameter set at some point so the host can deal with the data appropriately. Syncing is currently done by serialisation into a string param (or in the future, a binary blob param).
Note that private data should not be used to cache intermediate computations (such as motion vectors). We need a separate cache suite for that.
There is an action, kOfxActionSyncPrivateData, which a host calls when it needs the plugin to serialise its private data into OFX parameters. Currently the documentation of how to manage private data and how to sync that data to persistent parameters is unclear.
Furthermore, when a host needs to calculate a cache signature, the host application needs the plugin to sync it's private data into the parameter set. This is potentially expensive and could lead to a noticable decrease in performance, eg: a point on our custom roto spline being dragged interactively would make the entire (possibly large) spline set be synced back at every pointer move before a render, just to calculate a hash.
Better documentation of the private data syncing mechanism would help alot.
To minimise the number of private param synchronisation events we need to have the plugin generate a signature for the private data on behalf of the host application. This will require…
(Pierre Jasmin): I am not sure this needs to wait for V2. Anything else than the render call in OFX need parallel Instance Data usagey? Ideally SyncPrivateData should be only for save, auto-save, duplicate node,...
Side comment: Right now there are different behaviors including - 1) people that don't have interrupt, 2) people that have a timer - abort and fall back to a lower resolution (possibly to draft mode if that feature is supported), and 3) people that abort all the time so the image is only evaluate on mouse up or if the slider stops moving for long enough for the render to go through.