Update to ofxInteract for drawSuite needed

[PierreJasmin_REVisionEffects]

We have been discussing a small mod to ofxInteract.h

to create a V2 Interact suite that requires to use the ofxDrawSuite, so that:

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

For now the functions pointers in the suite V1 and V2 would be the same, so it's totally soft implementation wise (just a different pointer on load).

Additional Notes:  It proved insufficient for hosts that don't want OpenGL calls to stop that.  And historically we proved that just a doc change and API version based doc change was not sufficient, there has to be a clear entry point marker, hence V2 suite.

That said, as we are touching ofxInteract.h,  anything else should be noted now before we push a candidate?

Pierre

[Gary Oberbrunner]

I'm not sure I'm understanding the use case. As it is now, a plugin can detect whether the host supports the ofxDrawSuite. So it may use it if it exists, and if not, use OpenGL. So the point of this change would be for the host which supports the draw suite to be able to tell a plugin (which also supports the draw suite) "definitely use the draw suite, do not use OpenGL"?

--
-- You received this message because you are subscribed to the Google Groups ofx-discussion group. To post to this group, send email to ofx-dis...@googlegroups.com. To unsubscribe from this group, send email to ofx-discussio...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/ofx-discussion?hl=en
---
You received this message because you are subscribed to the Google Groups "ofx-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ofx-discussio...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ofx-discussion/e9ffbd8a-dd57-4382-84b8-7fa3c5ec22f8n%40googlegroups.com.

--

Gary

[Gary Oberbrunner]

The discussion started with Alexandre asking this:

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?

These two things seem like they could be addressed with properties. A plugin could set kOfxImageEffectPropWillUseDrawSuite on its effect descriptor to tell the host it will only use the draw suite (once it has determined that the host supports it), so perhaps it would have to set it in DescribeInContext. This seems like a nice handshake. We can specify that a plugin must do this if it intends to use the draw suite.

As for a plugin being usable without interact, we'd have to specify in more detail how the handshake should work and what the behavior is. Let's say the plugin sets this prop in its effect descriptor during Describe, but then what happens? Does the host not load that plugin at all? What if it's in use in the comp? Maybe the host should just not allow adding new instances (gray it out etc.)? And how early can the plugin know this? Some will know it at load time, but for others could it be context dependent? E.g. it works as a filter, but not in general context?

--

Gary

[PierreJasmin_REVisionEffects]

Actually someone from Fusion (the BMD app) asked before and I thought we would be good, but I see it could create a dependency order if not otherwise specified.  The primary goal is to protect hosts from plugins that were compiled before DrawSuite was supported.... so they don't send OGL overlay draw calls....

Seems If fetchSuite(mHost->host, kOfxDrawSuite, 1); returns not NULL wouldn't kOfxImageEffectPropWillUseDrawSuite be redundant to fetching suite?  If you fetch suite, then the intent is that you will use it, no?

We also have kOfxImageEffectPropSupportsOverlays that I see we don't check here, I guess, we assumed here that if OfxInteractSuite is supported that we can draw, perhaps InteractSuite could also be used for just hot keys...  :)   -- 

 kOfxImageEffectPropSupportsOverlays theoretically could also add a 3rd option and be modified as below,  and that would also be legit... and more complete.

• Type - int X 1
• Property Set - host descriptor (read only)
• Valid Values - This must be one of // not sure if we need 3-, 1 and 2 supported?
  
  • 0 - the host won't allow a plugin to draw a GUI over the output image,
  • 1 - the host will allow a plugin to draw a GUI over the output image with OpenGL
    
  • 2 - the host will allow only a plugin to draw a GUI over the output image if they use the DrawSuite
    

I thought it was more robust to just do fetchSuite(mHost->host, kOfxInteractSuite, 2);   but I am not sure it matters.

mInteractHost = (OfxInteractSuiteV2*) mHost->fetchSuite(mHost->host, kOfxInteractSuite, 2);
if(!mInteractHost) { 

        mInteractHost  = (OfxInteractSuiteV1*) mHost->fetchSuite(mHost->host, kOfxInteractSuite, 1);
        // assumes OpenGL or whatever special host case you might already be doing

}

if(mInteractHost) mDrawHost = (OfxDrawSuiteV1*) mHost->fetchSuite(mHost->host, kOfxDrawSuite, 1);  // if mDrawHost == NULL, use OGL ok

Aside from that, plugins have all the means to bail out if some suite needed is not supported or modify their UI.
Host that load plugins for background renderer will never callback interact suite so a non-issue. Some hosts in GUI mode mute that forcing a user to turn that on interacts in their UI somehow, so it's possible to guard against a plugin not fetching DrawSuite. Others callback Interact only if effect is the one selected...  So maybe host who don't support OGL overlays just never calls Interact callbacks if DrawSuite is not fetched. So I am back to where we started :) - Host can block plugin against that, it's not very dangerous. I just don't know if someone use cursor position without overlay drawing for something...

 Pierre

[Gary Oberbrunner]

The primary goal is to protect hosts from plugins that were compiled before DrawSuite was supported.... so they don't send OGL overlay draw calls....

Can other folks interested in this chime in here? Is this the actual need that we should try to solve? Are there other considerations? And what would the desired behavior be?

As Pierre suggests, is it sufficient if the standard specifies that when a non-OpenGL-capable host loads a plugin that doesn't request the draw suite, it should (or may?) disable the interact suite (never call the actions)?

To view this discussion on the web visit https://groups.google.com/d/msgid/ofx-discussion/63068e76-d66a-4ff0-9d6a-862ba33c282en%40googlegroups.com.

--

Gary