site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com On Mar 17, 2009, at 7:11 AM, Paul Miller wrote: _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... Steve Christensen wrote: On the first call to renderOutput:... my plugin loads an external image file to use as part of its effect. Since render performance would outright suck if I loaded the image and then tossedit after rendering each frame, I keep the image in memory and dispose of it in the plugin's dealloc method. While doing some testing I noticed that instances of my plugin get created as it is associated with a clip but don't get deallocated until either the project containing the clip is closed or FCP quits. This suggests that if there are enough clips using my plugin, for example, then application memory could get tight. Based on my understanding of the FxPlug API, there doesn't appear to be a way to determine that rendering is really done, or at least the plugin won't be needed "soon." Does this mean I have to hope that a user doesn't overload FCP's memory and cause a crash? It's possible your undeleted clips are in FCP's undo buffer, and will eventually get deleted when the undo buffer overflows. I'm just guessing. I suggest you share your loaded image data between all instances of your filter using some kind of singleton/shared data approach. The image data, in the worst case, is different for every plugin instance so sharing doesn't necessarily improve the situation. This email sent to site_archiver@lists.apple.com