site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com On Mar 17, 2009, at 7:36 AM, Paul Schneider wrote: On Mar 17, 2009, at 9:25 AM, Steve Christensen wrote: That's what I thought, at least regarding the SDK. On Mar 17, 2009, at 7:10 AM, Paul Schneider wrote: On Mar 17, 2009, at 1:57 AM, Steve Christensen 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... For this particular case, the per-plugin big chunk o' memory is an image of arbitrary size. I already play games by just using a bitmap representation and scaling larger images down to something more manageable, trading off image quality against memory usage (which also improves rendering performance). If FCP were to keep only those plugin instances that are being used (however that's defined), that would help to decrease the memory pressure, but plugins might still have to handle the case of running on older versions of FCP. The more problematic thing for my case, though, is that FCP seems to be keeping plugin instances allocated permanently, even if a particular clip hasn't been touched anytime recently. FCP may do some periodic deallocation of less recently-used instances but I didn't see that happening. That's true. We could periodically deallocate plugin instances for clips that haven't been recently touched, but we don't currently. That might help for plugins that maintain a lot of temporary or cache memory, but it wouldn't do much for plugins that maintain a lot of persistent memory, perhaps in custom parameters. If your plugin maintains a lot of data that can be regenerated if necessary, the best thing to do is to use the singleton approach to manage the memory across multiple instances of your plugin. Of course, this breaks down if the user has multiple instances of plugins from multiple vendors, each implementing their own static pool of scratch memory. But it does greatly contain the problem. The more problematic thing for my case, though, is that FCP seems to be keeping plugin instances allocated permanently, even if a particular clip hasn't been touched anytime recently. FCP may do some periodic deallocation of less recently-used instances but I didn't see that happening. We've discussed the need for better communication with plugins: - howMuchMemoryAreYouUsing, -pleaseTossAnyCacheMemory, that kind of thing. Right now, there's nothing in the SDK in that area. For now, you'll have to manage memory yourself. One strategy might be to keep a static array of images around, that all instances of your plugin share. You can cap the size of the array to some reasonable size (5, 10, etc). That way, if a user adds multiple instances of your plugin that point to different images, you can toss the least-recently-used image as you add a new one. If the many instances of your plugin can share the same images, even better. That's probably the best thing to do until we allow better communication between plugins and hosts with regard to resource management. 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? This email sent to site_archiver@lists.apple.com