Re: FCP plugin memory usage
Re: FCP plugin memory usage
- Subject: Re: FCP plugin memory usage
- From: Steve Christensen <email@hidden>
- Date: Tue, 17 Mar 2009 10:57:08 -0700
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.
On Mar 17, 2009, at 7:36 AM, Paul Schneider wrote:
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.
On Mar 17, 2009, at 9:25 AM, Steve Christensen wrote:
That's what I thought, at least regarding the SDK.
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.
On Mar 17, 2009, at 7:10 AM, Paul Schneider wrote:
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 Mar 17, 2009, at 1:57 AM, 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?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden