October 2019 - Pro-apps-dev

Re: Floating Window with the FxPlug additional UI
by Tomasz Huczek via Pro-apps-dev 08 Oct '19

08 Oct '19

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=il1/3PoGfKjlybatL2S92xm+dMWD57dbGPOjtTKIopE=; b=FMWdyqzXthSqbXsgdClzfxGmGys72q45L/asEjNb1yrgl25wUnPSBfkinOaN7/Xo9g N8hB4Tb9WnTxq3iVEmRlTe4JsIlzJYXKH6pLMyLd+IW2X4bVPeaUxTjYZ8ACJhAguGJ+ ngrWrRRb4+rYjfjKMks4fTnYHaNb/4lhK4VynrtlNYWBPX3P3qvwbY9IVLKHVivp6cks rgBGTRDhf/mzVKl5wTEX2biVSKuapMelGaBIzhSIgKAh9Vv5aeFKzv91fb/MExHju2pP +fxD5hsVqvlixE90zxe9mObUvXEXCpfbeKaKnTpybebn/0+uGAC8jalX6QrRYph+rrpq 8kRQ== 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 <dcardani(a)apple.com>, 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 > > <pro-apps-dev(a)lists.apple.com> 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 <dcardani(a)apple.com>, wrote: > > > > > > > > > > On Aug 26, 2019, at 2:33 AM, Tomasz Huczek via Pro-apps-dev > > > > <pro-apps-dev(a)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: > > > > > > > > > > > > 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 (Pro-apps-dev(a)lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com > > > > This email sent to dcardani(a)apple.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Floating Window with the FxPlug additional UI
by Darrin Cardani via Pro-apps-dev 08 Oct '19

08 Oct '19

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com 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 > <pro-apps-dev(a)lists.apple.com> 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 <dcardani(a)apple.com>, wrote: >> >> >>> On Aug 26, 2019, at 2:33 AM, Tomasz Huczek via Pro-apps-dev >>> <pro-apps-dev(a)lists.apple.com <mailto: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(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/pro-apps-dev/dcardani%40apple.com > > This email sent to dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Floating Window with the FxPlug additional UI
by Tomasz Huczek via Pro-apps-dev 08 Oct '19

08 Oct '19

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=H+0XGb4bn4wRcStUnOVDFqBJaYXOT2ZG7IfLvPZPQxo=; b=ZCGoLRaZqH5nuLRoFKulqRXmDkUDgRA19mnQGOqFCGjAVein/Yp+pHnnFIvmziltPG 1zW61DOmh9jp+TUM3whlk1E5vm3y6YnnqRIprXXsyjfKa9U/izwPQusakkFdwb/j2MNn 6RMPPBzTKbMXaDetub1ujibtTYNADs4MuWdUNhN4Wa1AV6VOwr+eVZiIUP44tcvMTV5q UNxnpjwP/lcMTsrKF2DK1RpCaNL6uEQl+72ldjqRKPRwRWy395cwlLF+YN3ipBItbh/u LmFVrG26XfTp4GXDKuoE9RuOCRSCH0ZnkClzMZ4D9Wt7hNU5aFCzRWSCFhZN25inWD5d U93A== 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 <dcardani(a)apple.com>, wrote: > > > > On Aug 26, 2019, at 2:33 AM, Tomasz Huczek via Pro-apps-dev > > <pro-apps-dev(a)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: > > > > > > 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 (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0