-
Notifications
You must be signed in to change notification settings - Fork 119
Extending OpenFX Guidelines
This page is meant to gather guidelines and tips to extend or modify the OpenFX standard.
-
First, a new standard change proposal should be submitted in the issue tracker page. Please use the standard-change proposal template rather than opening a normal issue. That template contains the standard-change workflow checklist.
-
The issue should be labelled by the repository maintainers according to its nature: bug-fix, enhancement, etc... and also (optionally, once this is known) a version milestone, e.g: 1.5, 2.0, etc...
-
Once the discussion has agreed onto a potential solution, one should actually implement the proposal
-
The proposal should the be proposed for review using a pull request. The pull request must reference the issue it is linked to using the tag of the issue, e.g: "#16", so that it makes it easy for reviewers to link issues to pull requests.
-
The pull request should target the development branch for which the issue had a milestone for: If the issue is targeted for milestone 1.5, the pull request should be made on branch RB-1.5
-
Discussion can happen on the pull request until the final version is approved and can be merged into the corresponding official branch
Functions signature in a suite should always have a PropertySet handle parameter corresponding to the inArgs of the action from which they are called. Without this context, the host may in some situation loose context awareness and rely on things such as thread-local storage to correctly retrieve the context of the action. Suites proposed to the standard without the inArgs PropertySet handle for each function would be declined.
E.g: The ImageEffect suite V2 should re-work all its functions, including the abort function to pass the inArgs of the current action, so that a host running concurrent renders with multiple threads knows which render to stop:
int (*abort)(OfxImageEffectHandle imageEffect, OfxPropertySetHandle actionInArgs);
As described in the developper FAQ, a property on a clip may be accessed on the output clip as-well.
In OpenFX, the output clip is an abstraction of the actual ImageEffect instance but since a lot of properties would be shared between an ImageEffect instance and a Clip instance, instead of duplicating properties we created the output clip. Problem is, the standard is not constrained enough about when the properties can be queried on the output clip instance. Typically, kOfxImageEffectPropPreMultiplication on the output clip can only be known on after the kOfxImageEffectActionGetClipPreferences action has returned. However if a plug-in chooses to get the value of this property within this action, this is undefined behavior and nothing is preventing this to happen.
A good practice would be to document as much as possible these type of unwanted recursions as much as possible in the standard, until we come up with a better abstraction in the standard (maybe for 2.0?)