site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com
On Aug 26, 2019, at 2:33 AM, Tomasz Huczek via Pro-apps-dev <pro-apps-dev@lists.apple.com> wrote:
Hello everyone,
I develop a FxPlug that requires some custom user interface which cannot be expressed using built-in controls. I’ve seen some plugins that use floating windows and was wondering what’s the best way to do that.
What I’m doing now is:
Have a button in the inspector to create a floating window, When the button is pressed I create new window (or show if it has already been created) using FxWindowAPI (and store it statically - 1 instance per FCPX process), On each FxOnScreenControl::initWithAPIManager call I update the apiManager pointer linked with the above window (also some static variable per FCPX instance). Is this the right way to do it?
That seems like a reasonable way to do it. However, you say “when the button is pressed I create a new window (or show if it has already been created)…1 instance per FCPX process)”. What happens when the user presses the button on one instance then presses the button on a second instance applied to the same footage? It might be better to have 1 window per plug-in instance if it would make sense to have 2 of them opened at the same time. That would probably also solve the first issue you’re having below (though it might make the second one worse).
The issues I’m having:
I need to click the plugin instance in the inspector to actually instantiate the FxOnScreenControl and get the pointer to the apiManager when going over the timeline. Is there a way to fetch it automatically? I don’t know of a way to fetch it. But if each plug-in instance had its own window, you could pass it into the window or view controller when you first create the window. If I’m using OpenGL within the floating window the performance is compromised by background rendering (I’m using a shared OpenGL context to have access to textures created in FxOnScreenControl). Each machine only has so many resources. If someone else is using the GPU, then your code will wait for it and vice-versa. I’d work on optimizing your GPU-related code as much as possible to keep the contention to a minimum. You can always advise the user that background rendering has an impact on using your plugin’s interface and leave it up to them to turn off background rendering or set the threshold of when to start to be a longer time period. From my tests, looks like temporalApi::getInputTexture doesn’t really work properly, I have to use temporalApi::getInputBitmap, any particular reason behind that? Sounds like a bug. Can you please file a Radar about that with a minimal example that shows the issue?
Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com