I am struggling with slow rendering and was wondering if having too many plugins can be an issues.
I looking at other posts and see how there are other ways to speed things up. I'm also going to check my ram to make sure it is all good.
This is my current set up -
IMac (Retina 5K, 27-inch, 2017)
Processor 4.2 gas quad-core intel core i7
Memory 64 GB 2400 Mhz ddr4
Graphics Radeon Pro 575 4 GB
I am not much of a tech but I'd assume that I should fly through most of the projects I do (most 3 - 10 min in length) but it seems so slow sometime and I do get the beach ball on occasion.
KScha wrote: ...struggling with slow rendering... I'd assume that I should fly through most of the projects I do (most 3 - 10 min in length) but it seems so slow sometime and I do get the beach ball on occasion...
When you say "slow rendering", do you mean exporting to a file or rendering the timeline to cache or both? Or do you mean scrubbing through the timeline is laggy and slow?
Can you give more info about what codecs from what cameras? Is it 4k? Is it H264? Is it single-camera or multi-camera? If uncertain, play a couple of clips in Quicktime Player and do CMD+I. That will show you the media and codec info.
Re beach ball, that is not really an indicator of slowness but that something is wrong or software or plugin is poorly written. A beach ball is not a "busy indicator" but means the app has quit responding to events for several seconds. Ideally you should never see a beach ball, because a well-written app either does asynchronous (ie non-blocking) API calls or offloads time-consuming tasks to other threads. However there are limitations in MacOS and related frameworks which require that certain APIs be called from the main thread which also runs the app's UI.
Further complicating this is the programming and threading model in the current FxPlug 3 framework which plugin developers use. In this scheme all plugin code and threads run within the FCPX address space, so a plugin bug or simply a CPU-intensive plugin code path which does not properly yield every few seconds can cause a temporary beach ball. As plugin developers migrate their code to FxPlug 4, this problem should be reduced:
For the above reasons it's important to be *very* selective about what plugins you install and use, and also keeping those plugins updated.
It can help to isolate performance problems between several areas: user interaction (e.g navigating and editing the timeline), rendering and exporting. Also isolate whether effects are involved.
The first step is disable background rendering in FCPX preferences, then delete all cache files via File>Delete Generated Library Files>Delete Render Files>All. After that select all clips in the timeline with CMD+A, then do a one-time render of those via CTRL+R. Do not use the machine while that runs.
Once it finishes no render dots should show above the timeline. Scrub back and forth in the timeline and evaluate performance. If export was slow before, try exporting the pre-rendered timeline using this preset: File>Share>Mater File>Settings, Format: Computer, Video Codec: H.264 Faster Encode, Resolution: 1920x1080.
If any problems with those, state the results. If your source material is 4k H264, that can be sluggish to edit on almost any Mac. In some cases you may need to create proxies or optimized media.
If you have (or suspect) very compute-intensive plugins such as Neat Video, update to the newest version which is faster. If still unsure of plugin contribution to your performance problem, make a snapshot copy of the project. Right-click on the project icon and pick "Snapshot Project" (in 10.4.9), then open the snapshot. Select all timeline clips with CMD+A, then remove all effects using Edit>Remove Effects. Navigate the timeline, and do the above export. Time that export and compare to the one with effects. That helps determine what % of the problem is simply a difficult codec vs what % is from effects.
FCPX itself has had recent performance upgrades, starting with FCPX 10.4.8 and continuing in 10.4.9. For some workflows, codecs and effects, it is significantly faster than 10.4.6 or earlier. If you have not upgraded to these versions, consider doing that. As always it's wise to fully back up everything before upgrading (especially FCPX libraries). In /Applications, use Finder to right-click and duplicate the Final Cut Pro.app file. That allows easy roll back to the previous version if you encounter a problem.
Most plugins in my library are from Motion or PixelStudio. I have a few from other places but primary rely on those two sources. I just have a lot in the library and just added a bunch more and didn't know if that was an issue.
Thanks for the info. I know there is a lot of the technical that i could improve but I'm not very good at the tech side of things. Most of my videos are for in house productions at our church and I usually can get by with what is going on I just think that somethings should be faster than they should be. Maybe also be I could be experiencing what is "normal" I just don't know better. I'll check out some of the things you suggested.
After looking at some other posts I may have found a suggestion on how to run a bit faster. My current practice to to load all clips into the library when I import them. I understand that keeping them out of the library and into a separate source folder my help with speed and performance. Any thoughts on that?
KScha wrote: ... My current practice to to load all clips into the library when I import them. I understand that keeping them out of the library and into a separate source folder my help with speed and performance. Any thoughts on that?...
That will only make a difference if you have an IO-bound problem. If it is CPU or GPU-bound, that won't help. The fact you mention periodic "beach balls" and lots of 3rd-party effects (inc'l Pixel Film Studios) implies it could be compute-bound. A chain is only as strong as the weakest link. If the weak link is computation from (a) Plugins or (b) A difficult codec, then improving I/O won't help.
That said, even if IO is *not* your current problem, it's generally a good idea to have the library and cache on a separate (preferably SSD) drive than the media. The IO stream to library and cache includes lots of small random IOs which conflicts with the large sequential IOs required of media.
If your system drive is HDD or Fusion, you definitely don't want the library, media or cache there. If it is SSD, in theory there's sufficient IO bandwidth, but typically the internal SSD isn't big enough so it's a moot point.
To place cache on a designated location, select the library in FCPX and in the Inspector at upper right, pick Storage Locations>Modify Settings>Cache>Choose, and pick an external SSD drive. Note if on Catalina and not running 10.4.9, there is a bug which can hang FCPX if you try to create a folder in that dialog. To workaround that create the folder in Finder, do CMD+I, scroll to bottom and grant Read/Write access to user "Everyone", then click the gear icon and pick "Apply to Enclosed Items". After that use FCPX to designate that folder for Cache.
It is more likely you have a compute-intensive issue due to the 3rd-party plugins. Do the previously-stated timed tests about rendering the timeline vs exporting, both with and without effects, to determine where the problem is.
pszilard wrote: Not sure if the OP was talking about just having plugins installed, but not applied to the timeline, OR having many plugins actually applied.
I have a ton of plugins installed, but rarely use more than a handful on any one timeline. I expect that should not matter. Can anyone confirm this?
Normally a slowdown happens from *using* the plugin. Less commonly, just having the plugin installed can cause performance or stability problems. I have had a few FCPX crashes caused by a plugin which was installed but not used in any project. This was confirmed by the plugin mfg, also the crash report showed their code inside FCPX address space.
However I've examined other people's crash logs which show plugin code within FCPX address space, even though they had not applied it to a timeline. I don't remember which ones.
I'd say just not applying the plugin or 3rd-party effect is about 80-90% safe. But simply having it installed (though not applied) has some risk, especially if you have a ton of them.
This will hopefully be improved with the FxPlug 4 architecture that runs plugins in a separate, isolated address space. But plugin developers must re-write their code for that. Realistically that may not happen until after the ARM transition.