On 9/2/2014 4:38 PM, Paul Schneider wrote: Hi Paul and Gabe, Paul, your symptoms sound like the problem might be texture memory growing unbounded. I believe the GL driver will allocate memory for textures outside of the app’s address space. Are you viewing “My processes” or “All processes” in activity monitor? Hi Paul! You might also try Open GL Profiler and/or vmmap to see if you can get a better view of texture and memory usage. Okay. Gabe’s description of memory being released after every frame in FCP, but not until the end of the render in Compressor, is interesting. My uninformed guess is that as a headless process, ProMSRenderingTool either doesn’t have a run loop, or doesn’t service the run loop between frames when rendering. It’s possible that either your code or our code is scheduling some cleanup for idle time using dispatch_async or performSelector:afterDelay: or some other mechanism that relies on the run loop to be serviced. Cheers! -Paul - Paul On Sep 2, 2014, at 12:36 PM, Paul Miller <paul@fxtech.com <mailto:paul@fxtech.com>> wrote: On 9/2/2014 11:07 AM, Paul Miller wrote: On 9/2/2014 10:43 AM, Paul Miller wrote: I watched a render today in Activity Monitor. While it was rendering, Memory usage of ProMSRendererTool hit about 2GB and then was stable, hovering around 1.81GB. compressord hung in there at about 128MB for the whole time. After about 20 min I got the "Your system has run out of application memory" dialog box. BTW - I tried again with a simple project with one long clip and a third-party filter that isn't one of mine, and got the same results. Despite ProMSRendererTool only showing between 1.5 and 1.9GB used in the Memory column, I can see Virtual Memory and Swap Used steadily rising, about 125MB/sec. I think there is a problem with Compressor. Of course, this doesn't happen when using a built-in effect, such as FCP's Night Vision. ProMSRenderingTool hangs out at 440MB. Memory Used creeps very very slowly. Perhaps the problem only occurs in 3rd party fxplugs? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com <mailto:Pro-apps-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com This email sent topschneider@apple.com <mailto:pschneider@apple.com> _______________________________________________ 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 Yes - that sounds like it may be the case. Both of the filter sets I tried are using the OpenGL path. Interesting. Since it appears that FCP-native effects don't seem to be affected by this, are they implemented using the exact same FXPlug mechanisms as ours would be, or do they have a different path? I couldn't tell if you thought this was a bug in our code, or in Compressor. Should I file a radar?