Re: Floating Window with the FxPlug additional UI
Re: Floating Window with the FxPlug additional UI
- Subject: Re: Floating Window with the FxPlug additional UI
- From: Tomasz Huczek via Pro-apps-dev <email@hidden>
- Date: Tue, 8 Oct 2019 20:44:08 +0200
That’s a fantastic news! Somehow I missed the info about FxPlug 4.0 release.
Thanks again.
Tom
On 8 Oct 2019, 18:06 +0200, Darrin Cardani <email@hidden>, wrote:
> Starting with FxPlug 4, which was also released yesterday, you can use
> whatever rendering technology you want, including Metal! With FxPlug 4
> plugins are completely out-of-process, so they can use Metal or anything
> else. FxPlug 3 plug-ins will continue to work for the time being but will
> remain OpenGL-only.
>
> Darrin
>
> > On Oct 8, 2019, at 12:20 AM, Tomasz Huczek via Pro-apps-dev
> > <email@hidden> wrote:
> >
> > Thank you Darrin, that helped a lot!
> > One more question though - with the release of new Final Cut Pro version
> > 10.4.7 the first item on the list is the new Metal-based processing engine.
> > Is FxPlug API going to be updated to give us direct interface to Metal
> > resources?
> > Currently, there’s only OpenGL interface and looks like it’s not the best
> > way to go anymore…
> >
> > Thanks for your time,
> > Tom
> > On 26 Aug 2019, 18:28 +0200, Darrin Cardani <email@hidden>, wrote:
> > >
> > >
> > > > On Aug 26, 2019, at 2:33 AM, Tomasz Huczek via Pro-apps-dev
> > > > <email@hidden> 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:
> > > >
> > > >
> > > > 1. Have a button in the inspector to create a floating window,
> > > > 2. 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),
> > > > 3. 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:
> > > >
> > > >
> > > > 1. 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.
> > > >
> > > > 2. 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.
> > > >
> > > > 3. 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 (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> >
> > This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden