Extending OpenFX Guidelines

This page is meant to gather guidelines and tips to extend or modify the OpenFX standard.

Submit a proposal or bug report to review

• First, a new standard change proposal should be submitted in the issue tracker page

• The issue should be labelled by the repository maintainers according to its nature: bug-fix, enhancement, etc... and also 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

Suite functions signature

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);