Are you suggesting the blobs would handle ownership of memory allocated by the plugin, to avoid copying? I'm not sure if the added complexity of this is better than a simple copy on write, assuming read could be just passing a pointer back.
Standard version: 1.5
Minor Change
Plugins with private data currently save their values into custom params, which are simply strings. It would be more efficient to allow plugins to encode/decode serialised data with a binary blob.
We add another param type, kOfxParamTypeBinaryBlob, which can be used to store binary data. Such params have the following properties….
kOfxPropDataSize - 64 bit unsigned integer indicating the size of the blob
Question?
Do we need another suite to manage binary data blobs, basically allocating and freeing the things. Or should we just use the memory suite and allow allocation from that?
Are you suggesting the blobs would handle ownership of memory allocated by the plugin, to avoid copying? I'm not sure if the added complexity of this is better than a simple copy on write, assuming read could be just passing a pointer back.
(Pierre Jasmin): This needs more general discussion. To recap we have an FR for signing customData (so it does not need to generate excessive synch data - which should be just to save to disk and similar). We have transient data (internal cache) that can be frame dependent (e.g. a cache per input frame time requested) - by transient we mean is not to be stored in project. This can be a way to speed up interaction for example. It's not necesary image buffers. And we have internal database structures that are not necessarily fully saved as parameters (or savable as). This (or something) should be writable during render call for the render multiple frames at once type of scenario.
I think this could be useful - but perhaps if I could lock this during UI to update and force an abort during render (so the same pointer is passed to render thread(s)). Right now in render thread abort() is something the host requests, there is not a designated return message to force rerender. What I am describing could be an indirect way for us to deal with hosts that don't implement abort as well. ?
To answer Paul, I don't think right now (although it's not documented you can't) we can write to InstanceData in render call for example. This is known to have no effect in some hosts of course.