×

Terminal Output

  • Welcome
  • Standards Discussion
  • Contact
  • Ofx small
  • Welcome
    • Why a Standard?
    • For Implementers
    • Association Business
  • API Documentation
    • API Reference
    • Programming Reference
    • Programming Guide
  • Standards Discussion
  • Contact
Back to standard change list


Binary Custom Params Proposed

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?

 

Back to standard change list


Discussion

Comments

(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.

Pierre Jasmin | 5:48 pm, 6 Jun 2015

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.

Paul Miller | 8:51 am, 24 Feb 2015
Back to standard change list
  • OFX @ Github
  • Association Information

Copyright ©2023 The Open Effects Association