Javascript -- when does it evaluate?

lunelson's picture

OK, so the answer to this question is probably in a FAQ somewhere; but I can't find it.

I remember reading something about how Javascript patches don't necessarily evaluate on every frame -- that they needed some kind of dynamic input (like Patch Time or something) to make them do so. Is this true?

Also: would the opposite case be true? -- that if you use a JS patch to generate a Structure for example, that it won't be regenerating on every frame, but rather only if you change any of its inputs?

Thanks for any tips, enlightenment

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cybero's picture
Re: Javascript -- when does it evaluate?

Yes , JS patches need a dummy input to keep the process running. Otherwise the problem is likely as not in the JS code itself. Of course there could be some other reason we wouldn't know about unless we saw the composition.

Have a closer look see at amongst other threads for further examples and guidance.

Oh , and BTW, if you have one good working JS based comp rendering at the same time as a badly scripted example then you can expect both to slow down - considerably.

Examine in isolation - only render on view at a time.

cwright's picture
Re: Javascript -- when does it evaluate?

Like cybero said: it only evaluates if an input changes.

If an input doesn't change, it doesn't evaluate.

easy as pie.

That said, when you edit the code, it executes twice: once in "testmode", and then once for real. in test mode all inputs are null, which can sometimes cause an otherwise-functional script to break.'s picture
Re: Javascript -- when does it evaluate?

The Javascript patch also has a little quirk in that it will re-execute if you move any patch in the Editor window, even if the all the inputs are unchanged.

The attached comp feeds the JS patch output back to the input. When the Viewer window is active it executes continuously, incrementing the number.

When the editor window is in focus, it stops but if you move the JS patch (or any other patch), the number increments twice indicating two executions of the patch.

iterative.qtz3.69 KB

cybero's picture
Re: Javascript -- when does it evaluate?

Another one for the the strange but true world of JS in QC.

As it happens, when moving patches in the editor, I get only one extra number , 340 then 341 not say 340 then 342.'s picture
Re: Javascript -- when does it evaluate?

I'm on Leopard could that be it? I made this comp a fair while back and my memory is that it one incremented by one. Definitely 2 now on my Mac!

sbn..'s picture
Re: Javascript -- when does it evaluate?

I'm very cautious when I have to work with pathes that allow editing of code, JS or image kernel. (Expression seems reasonably safe).

Basically, I edit the script in TextWrangler. I save it there first, both to have a backup, a larger window, and to get the nice code highlighting. Then I copy the whole thing into the patch's textfield at once. Sometimes the testmode issues produces wonky behaviour, which is why I never trust the JS to work properly until after the whole composition's been saved, closed, and reopened without issue.

I guess we're seeing the divide between graph programming and the traditional way. The Blender game engine has a node structure of sorts, too, and it always stumps experienced programmers that there's no concept of "the game loop". In stead, both in QC and BGE, you're programming in a sort of open loop structure which gives a few extra headaches (you have to manage state a bit more carefully).

cybero's picture
Re: Javascript -- when does it evaluate?

if the interaction is provided in the viewer window is appropriated with a single mouse click , then an increment of 2 is achieved, but a simple wiggle results in just an increment of 1, likewise the 'trick' of moving patches on the editor stage results in only an increment of 1.

lunelson's picture
Re: Javascript -- when does it evaluate?

Thanks for all the answers!

toneburst's picture
Re: Javascript -- when does it evaluate?

I've not had many problems with the programming patches, except for the OpenCL one, which is horribly unstable. The JavaScript one is fairly stable though, in my experience.

Sometimes you have to force it to evaluate every frame. The easy way to do this is to have a __number input connected to a Patch Time patch. You don't have to do anything with this 'dummy' input in the JS code itself, it's enough to have a constantly-changing input going in.

And put all code inside

if(!_testMode) {

especially if you're using __structure inputs or outputs.


smokris's picture
Re: Javascript -- when does it evaluate?

toneburst wrote:
Sometimes you have to force it to evaluate every frame.

IMO this should be possible without the dummy-port workaround, though it currently isn't.

Filed radr://7674879 for allowing the user to select the timeMode of the Javascript patch.