Bruce Bullis wrote > "The following is the expected structure of execution. When functions are at the same " depth", > they are considered to be running in parallel..." I'm not sure what suggests to you, that these expectations properly apply to CEP panels...? [I'm not saying you're wrong, just wondering why you have these expectations.] What suggests this structure to me is the format of the API itself. In JavaScript, when you use an API that takes a callback, it is typically fair to assume that the API is asynchronous in nature (or, at least, that it can be). The format of CSInterface.evalScript follows that format: CSInterface.prototype.evalScript = function(script, callback) As a user, I look at that API definition and say "Okay, I'm sending a message from one 'JavaScript' context to another. I have no idea what the other context is doing or if it's even running right now. I will provide this callback to receive the result at some future time once the other 'JavaScript' context has completed its work." Bruce Bullis wrote > "...does the CSInterface evalScript function properly schedule a message and immediately return..." I don't understand your usage of "Properly", above. evalScript() does just that; evaluate a given snippet or file of ExtendScript. Let me be explicit about what I'm stating: Expectation: "As a user, I expect the CSInterface.evalScript function to schedule work to be done in ExtendScript. It should add a message containing the 'script-to-evaluate' to ExtendScript's internal message queue​​ and immediately return. When the ExtendScript context has had a chance to process that message, it will return a result. That result will be coerced to a string by the 'glue code' that understands the CEP and ExtendScript contexts. That glue code will then add the callback (the one supplied to the evalScript function) as a message to be called in the CEP context's message queue." What you've just stated is very different: "evalScript() does just that; evaluate a given snippet or file of ExtendScript." What this says to me is: Reality[?]: "The CSInterface.evalScript function will block the CEP caller and start up the ExtendScript context. It will then evaluate the 'script' provided in the parameter. If this work takes three seconds, then CEP will also be blocked for three seconds. A callback with the result will indeed be scheduled but it won't gain you anything over simply returning the value directly from the evalScript call as the calling CEP context was blocked for the entire time anyway." The expectation is that CSInterface.evalScript is asynchronous in nature - it is akin to sending a message to a separate context that will process it "in due time, thank you very much", rather than immediately. In other words, it's almost the CEP version of the ExtendScript context's CSXSEvent system. I mean, why even bother with the callback if you're simply going to block anyway? Just return the result directly! I checked what the CEP 8 HTML Extension Cookbook has to say about the evalScript function. Unfortunately, the writing isn't terribly clear, but it may be trying to say what I believe you confirmed above. Specifically, this section: Please be aware that the script in evalScript and the jsx file which is configured in <ScriptPath> in the extension's manifest are executed in host application's ExtendScript engine, which runs in host application's main thread. On the other hand, CEP event is also dispatched from host application's main thread. If the interaction between the script and CEP event is needed, please split the script into small parts and call them separately so that CEP event has a chance to be scheduled. Here's what I gather from this: Code passed as a string into evalScript and JSX files are processed on the application's MAIN THREAD. This is expected. There is one ExtendScript engine [context] in Premiere Pro and its work is done on a unified Event Loop. CEP events are dispatched from the application's MAIN THREAD. I'm unclear as to whether this means events from CEP, to CEP, or both... That last sentence is frustratingly ambiguous. "... please split the script into small parts..."... Which script? CEP-side or ExtendScript side? However, combine that with your comments: Bruce Bullis wrote That ExtendScript could block until execution is complete; this is the common case. OR, that ExtendScript could execute and return immediately, AND set up other ExtendScript functions to be called back, when some child processes are complete. PProPanel's usage of Encoder.encode() would do this. And it seems that, indeed, evalScript does block the CEP thread until it's done processing. To that end, to achieve a result that's inline with expectations, you should use the CSInterface.evalScript function to schedule work to be done in the ExtendScript context and have that code dispatch a CSXSEvent. All That Being Said... Will the ExtendScript context cause a noticeable glitch regardless of whether it's been scheduled to work asynchronously? The fear is that ExtendScript processing always occurs on the main thread (and blocks the application, CEP, etc.) rather than in its own thread. This would result in that long API call blocking the main thread and causing the noticeable hitch regardless of the work you do to make things asynchronous.
... View more