March 2009 - Pro-apps-dev - lists.apple.com

Re: FCP plugin memory usage
by Paul Schneider 17 Mar '09

17 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Paul, - Paul On Mar 17, 2009, at 9:58 AM, Paul Miller wrote: _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Can a plugin subscribe to NSTimer events, or would that be no-no? If so, a plugin could set up a periodic timer and flush caches every x minutes of inactivity or something. Though I don't know if this would play nicely with your real-time stuff. That might work. We mask timer events during playback, and I think that includes timers we didn't install. I think there's also some mach API to monitor the VSIZE usage of your process, and you might be able to use that to get notified when memory gets tight. Before starting down those roads, though, I'd encourage you to make sure you're solving a problem that affects your customers. Final Cut does set aside a certain percentage of physical memory for third-party allocations (codecs, plugins, etc) that we can't track. In our experience, sharing memory between plugin instances allows plugin memory to stay on the right side of this line, even in quite complex real-world projects. Of course, every plugin has different needs, so what works for us might not work for you. And of course, please feel free to add your voice to the requests for memory-tracking API via bugreport.apple.com. We really do pay attention to those reports, even if we can't promptly address each one. If we receive multiple requests for the same functionality, that can help us prioritize future releases. 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. Can a plugin subscribe to NSTimer events, or would that be no-no? If so, a plugin could set up a periodic timer and flush caches every x minutes of inactivity or something. Though I don't know if this would play nicely with your real-time stuff. _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com This email sent to pschneider(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP plugin memory usage
by Paul Miller 17 Mar '09

17 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209) 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. Can a plugin subscribe to NSTimer events, or would that be no-no? If so, a plugin could set up a periodic timer and flush caches every x minutes of inactivity or something. Though I don't know if this would play nicely with your real-time stuff. _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP plugin memory usage
by Paul Schneider 17 Mar '09

17 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Steve, - Paul On Mar 17, 2009, at 9:25 AM, Steve Christensen wrote: That's what I thought, at least regarding the SDK. steve On Mar 17, 2009, at 7:10 AM, Paul Schneider wrote: Hi Steve, - Paul 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 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? steve This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP plugin memory usage
by Steve Christensen 17 Mar '09

17 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com That's what I thought, at least regarding the SDK. steve On Mar 17, 2009, at 7:10 AM, Paul Schneider wrote: Hi Steve, - Paul 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 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? steve This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP plugin memory usage
by Paul Miller 17 Mar '09

17 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209) 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. _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP plugin memory usage
by Paul Schneider 17 Mar '09

17 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Steve, - Paul On Mar 17, 2009, at 1:57 AM, Steve Christensen wrote: steve _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 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 pschneider(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

FCP plugin memory usage
by Steve Christensen 17 Mar '09

17 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com steve _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 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(a)lists.apple.com

1 0

Re: plugin unexpectedly available in Motion
by Micah Sharp 13 Mar '09

13 Mar '09

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Invalidating preview cache in Motion
by Micah Sharp 13 Mar '09

13 Mar '09

site_archiver(a)lists.apple.com Delivered-To: Pro-apps-dev(a)lists.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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Invalidating preview cache in Motion
by Darrin Cardani 13 Mar '09

13 Mar '09

site_archiver(a)lists.apple.com Delivered-To: Pro-apps-dev(a)lists.apple.com On Mar 13, 2009, at 5:45 AM, Eberhard Ammelt wrote: Darrin -- Darrin Cardani 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… we have a problem with custom parameters in Motion (3.0.2). After creating a RAM preview in Motion (3.0.2), Motion ignores value changes of custom parameters, and does not invalidate the preview cache. I've tried a workaround with changing hidden and visible standard parameters programmatically, but it doesn't help. Is there any way to force Motion to re-render and invalidate the preview cache upon changes of custom parameter values? Nasty. Sounds like a bug. Please file a bug report if you haven't already. I know we've had a few bugs in the past regarding custom parameters and updating, so it's possible we still have a few more we didn't know about. My workaround would have been to try what you've already tried with an invisible parameter. I don't have any other ideas off the top of my head. (OK, if you wanted to try something really nasty that's extremely likely to break in the future, or even in different language versions, you could try convincing Motion to clear the Ram Preview cache by faking a menu event, or something like that. But I don't recommend it.) This email sent to site_archiver(a)lists.apple.com

1 0