×

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


Loss of host calling context on all suite calls. Proposed

Standard version: 1.4.1

Major Change

The API is meant to be called in a parallel manner, so that a host application may call actions on a plugin from any number of threads and have the API work. The only constraint on a plugin is that any calls back to the host via a suite must be from the thread the initial action was invoked from. 

This problem arises when a host calls actions in parallel. It may have some private data specific to the context if the action it called the plugin in. Without that context specific data, the call back to the host is impossible to compute.

Given the calling constraint on a plug-in, the only way a host can pass itself back any private data is to place it in thread local storage. This is somewhat painful, especially as the suite function called may trigger recursive actions back to the plugin.

We amend the function signatures of a subset of suite calls to take an extra argument. This would be the inargs property set handle passed into the action. The host can decorate the underlying host-side structure behind that handle with the context specific data it needs, so when the plugin passes back the inargs via one of those suite calls, the host can access it's needed private data and determine what it needs to do.

This would possibly remove the constraint on plugins as to which thread they can call suite functions on.

 

(sept 23, 2016):  This is near approved (approved enough for all new suites and versions to follow).

Note: It might not be important for MessageSuite and ImageEffect suite itself might be more a basket than the other suites and it would be occasion to fix incorrectly typed variables – which makes it even more a basket. Versioning ImageEffect suite itself, brings the next topic as well since it would probably only make sense if that suite was incremented.

http://openeffects.org/standard_changes/properties-that-are-doubles-canonical-but-should-really-be-ints-in-pixels-space

Mini action item: We probably need a volunteer to think about how we would change type to what they should be without causing too much harm, as it implies versioning some #define… so the consequences can be evaluated..

Back to standard change list


Discussion

Comments

DialogSuite seems to be another example of this.  There is a DialogSuiteV2 proposal being discussed on the members mailing list that could include this arg.

Gary Oberbrunner | 1:44 pm, 15 Sep 2015

About: Analysis pass case

Just a note -- Analysis action is now gone. The equivalent within InstanceChanged can be handled via the Progress Suite Cancel button.

Pierre Jasmin | 2:21 pm, 4 Sep 2015

As an example on the host-side, the function "abort" is crucial: it is meant to be faster and checked very often. Unfortunately it requires the host to keep Thread-Local-Storage (TLS) to know the state of the thread and to identify which render it belongs to.

Basically there are different types of renders: 

- Playback (or background) renders, where multiple frames can (could) be computed in parallel

- "Single frame" renders where the goal is to render a specific frame the fastest possible (typically after modifying a parameter, seeking the timeline to a particular point etc...)

- Analysis pass

Depending of the situation you may want to abort differently: In the case of the "Single frame" render, any newer interaction from the user should in most cases abort the - now useless - render. But for "Playback" renders you may for instance want to abort only once a button has been pressed.

For an analysis pass you may also want a different policy for aborting...

All these small bits needed to identify a render must be kept local to a thread and may be expensive to retrieve and copy onto each spawned thread, whilst we could in fact just hold it in a struct behind a hidden property in the inArgs. 

Alexandre | 3:12 am, 4 Sep 2015

(Pierre Jasmin): Another related area were this seems true is Overlay callbacks. (when you have two plugins that use OGL overlays)...  

Can't an host simply create unique 2D int for each EffectHandle instance internally and pass example effect 29.2 inside opaque handler.  Also if the plan was to allow an effect to be at different time in two viewers. For example host could on interact instance creation embed effect instance ID,...  ???  - this obviously needs host chiming in :)

 

Pierre Jasmin | 4:20 pm, 6 Jun 2015
Back to standard change list
  • OFX @ Github
  • Association Information

Copyright ©2023 The Open Effects Association