Overlay drawing API abstraction layer about openfx HOT 13 CLOSED

@VegasSebastian if your host supports the new DrawSuite, compliant plugins should use it. Of course older plugins won't, but they just won't work correctly in a non-OpenGL world, and that's something they would have to fix. So there's nothing more you can/should do than support the DrawSuite I think.

from openfx.

Using this instead of letting plugins use GL directly would be a big win for Baselight - currently we have to intercept all interact GL calls to route them to our separate rendering process which is often on a separate system. It works but I'd be delighted not to have to do it!

from openfx.

Hosts will require some means to determine if a plugin is going to exclusively use the draw suite. If we are not running in OpenGL, we cannot call interacts for a plugin that is going to make GL calls, without likely crashes/undefined behaviour.

It would also be nice to know if a plugin is usable at all without ihteracts. In some cases, they are merely convenience, but it is still usable via the parameters directly; in others the interact might provide the only means of effectively using the plugin.

As such, perhaps a describe-time property (or multiple) for the above cases would be desirable?

from openfx.

Folks following this issue: please try out the new draw suite in feature/drawSuite branch -- the extension is now in review. Submit PRs as needed, and discuss here.

from openfx.

	kOfxDrawTextAlignmentLeft = 0x0001,
	kOfxDrawTextAlignmentRight = 0x0002,
	kOfxDrawTextAlignmentTop = 0x0004,
	kOfxDrawTextAlignmentBottom = 0x008,
	kOfxDrawTextAlignmentBaseline = 0x010,

Bottom and Baseline are missing a 0 for consistent digit count.

from openfx.

Phil also mentions: "Comment - if I was reviewing this code, I'd fail it because of the use of enum values which the client code is expected to | together to pass to an int parameter to drawText(). IMHO they should instead be const [unsigned] ints, or #defines. But not going to hold things up for this. "

from openfx.

Sample image, with RE:Vision plugin executing in Scratch:

Shows all new primitives working per the spec. Demonstrates the requirement of working with one plug-in and a host from a separate company.

from openfx.

This is complete and merged now with PR #90.

from openfx.

Hosts will require some means to determine if a plugin is going to exclusively use the draw suite. If we are not running in OpenGL, we cannot call interacts for a plugin that is going to make GL calls, without likely crashes/undefined behaviour.

It would also be nice to know if a plugin is usable at all without ihteracts. In some cases, they are merely convenience, but it is still usable via the parameters directly; in others the interact might provide the only means of effectively using the plugin.

As such, perhaps a describe-time property (or multiple) for the above cases would be desirable?

Has this been explored further ? I have been wondering the same thing

from openfx.

There should probably be a V2 Interact suite that requires to use the DrawSuite.
Hosts that support OpenGL overlay draw can support both V1 and V2 without issues.
Hosts that can't support OpenGL overlay drawing would just support V2.
Plugins that don't know about V2, can still use OGL if V1 is supported.

• pierre

from openfx.

from openfx.

OK let's fast track that :)

I think if we just duplicate V1 suite and call it V2 and add as comment for V2 something like I said above, it's very soft as it's just a different pointer and the function pointers of the suite would be the same. There needs to be a code change somehow as it did not work well before to just tie a spec change as doc with a release version...

All I see with regards to Silhouette in our code is below, and otherwise turned off here until next release... we should check suite from 2022.0 for SIlhouette for now? We can follow-up offline...
if (mHost->isSilhouette())
{ // workaround in Silhouette v <= 2020.5.5 cannot set during createInstance. XXX TO DO: check if it's fixed in next version

which is not particular to drawsuite, and not uncommon issue not to initially be able to initialize spatial coordinates as the clip is not defined yet...

from openfx.

From the host perspective, how to tell a plugin that overlays are supported (kOfxImageEffectPropSupportsOverlays) but only using the draw suite? That would be the use case, If the host does not support OpenGL drawings. Even if OfxInteractSuiteV1 is reported as not supported, most plugins will start drawing using OpenGL.

from openfx.