SDK - What happens internally to processing when a frame is interrupted?

[Richard Rosenman]

Hi gang;

So I've got a plugin that I developed. It is computationally intensive so it takes some time to render a frame.

I found that if I advance through frames quickly in After Effects, it crashes. If I advance through frames slowly, allowing each one to fully render, it doesn't.

This means that interrupting a frame that hasn't yet been completed, results in crashing.

What I'd like to know is what does After Effects actually do when you interrupt the current frame processing to move to another? How does it interrupt the processing? Does it somehow abort it or does it wait for it to finish in the background? Is there a function that gets called whenever a frame is interrupted where I can do a clean up? If I understand this, I might be able to know how to approach a fix for it.

Thanks!

Richard

[shachar carmi]

AE doesn't just kill a rendering thread. it's up to you to call PF_ABORT() to see if AE wants you to stop the render process, and then return a PF_Interrupt_CANCEL error message to tell AE the output buffer is not to be used.

perhaps your crashes are happening due to re-entrancy? check if that's the case when advancing frame sbofre each finished rendering.

[Richard Rosenman]

Hi Shachar! 

As usual, you come to the rescue.. 🙂 Please bear with me so that I understand this.

In my testing, I can see that calling 

err = PF_Interrupt_CANCEL

indeed cancels the render. Since my render happens in the SmartRender function, I send the above error in the PreRender function and it successfully skips the SmartRender function. I assume this is how I should be doing it?

What I can't figure out is how to test if the user cancelled the render, and by cancel, based on my original message above, I assume that includes moving to a different frame, clicking on a button, etc, in mid-computation of the current one?

If so, then I would want to test if this has happened, and if so, interrupt the frame. Something like the following:

if (err = PF_ABORT(in_dataP)) err = PF_Interrupt_CANCEL;

 But I know this is incorrect.

Am I going up the right road in testing to see if a frame (or anything for that matter), was changed during the current frame computation and, if so, to abort it?

With regards to your suggestion about re-entrancy, I don't even know where to begin with that. I have found the source that is causing the crash (resizing a 2D matrix), and it doesn't crash if I don't interrupt the frame. It does if I do (for example, repeatedly move over 3 frames. So I figured the first attempts would be to skip it altogether if the user has interrupted the current processing.

Any suggestions?

Thank you as always - it's still a learning process but couldn't have gotten this far without your help.

Regards,

-Richard

[shachar carmi · Accepted solution]

so... we're dealing with multiple issues here.

1. interruption.

as far as i know, PF_ABORT should only be called and responded to durin a render call, and not the pre-render call.

the line of code you showed for checking for interruption (if (err = PF_ABORT(in_dataP)) err = PF_Interrupt_CANCEL;) is correct, you just need to make sure you return after it, so the said error message would be the one sent out.

in general, you should call PF_ABORT and PF_CANCEL when doing lengthy processing, as not to make the user's interactive experience choppy while scrubbing/chanign param values. you decide how often to check if at all.

2. the carsh.

the re-rentrancy theory seems more and more likely. however, on the basic level, if your crash occurs when accessing the matrix, then probably that matrix's infrastructure is not thread safe. is it a simple structure allocated in the stack, or is it some deep part of some 3rd party framework? (or perhaps a global variable?) if all fails, you'll probably need a mutex before handling it.
there shouldn't be a big mystery here.