Hi Brian: Thanks for the clarification on the behavior in Nuke - but it still strikes me odd that something seemingly innocuous like updating a text label field in a backdrop would cause all of the tcl python code in the script to evaluate (and per keypress). By the way, I've verified that our code updates only once per script update and not multiple times so it's not bug 16881.
To answer your question about the kind of usage: we are using these tcl python expressions to auto select filters in reformat nodes based on input criteria, or specifying the crop depending on the image size, or linking fields to custom global python values, etc. - these help standardize use of filters, image settings across the studio pipeline. When all this code executes at the same time because of a script change (like a keystroke in a text label), that's when it becomes an issue and could potentially pose an upper limit to the size of our nuke trees unless we restructure or remove our use of expressions. thanks for looking into this! =) Elvis ----- Original Message ----- From: "Howard Jones" <[email protected]> To: "Ben Woodhall" <[email protected]> Cc: "Nuke user discussion" <[email protected]> Sent: Friday, September 4, 2015 5:05:31 PM Subject: Re: [Nuke-users] python expressions locking up the gui Ok. Just checked and i only ever had a ticket number. Could you check to see if this is the same bug or similar. Ticket 2014081010000127 Howard On 4 Sep 2015, at 2:30 pm, Ben Woodhall < [email protected] > wrote: According to the bug it was submitted by Sean Looper. On 4 Sep 2015, at 11:54, Howard Jones wrote: <blockquote> Hi Ben Does this relate to the script I sent in then where the one slate / write combination could slow down a script? Or is that a different bug? Howard On 4 Sep 2015, at 12:12 pm, Ben Woodhall < [email protected] > wrote: <blockquote> Hi Elvis, I'm afraid that re-evaluating expressions on changing the tree is deliberate. Nuke does not yet track dependencies for expression evaluation (in spite of the expression arrows). This means that any changes in the tree can potentially change any other knobs (via an expression link). Bug 16881 related to animated knobs which were being re-evaluated several times per context (frame or tree change). If your expressions re-evaluate more than once per context then this is a recurrence of bug 16881. If your expressions re-evaluate once per context then I recommend that you raise a feature request for tracking dependencies to avoid re-evaluating nodes which are independent of modifications made in the tree (nodes, knobs or connections). We are aware that this can have significant performance issues with heavy scripts/nodes and are keen to hear from any other users who also have problems with performance when making minor modifications to big scripts (judged by the size of the nuke script or heavy use of expressions). Let me know if you need a hand getting the information out of your scripts. Thanks, Ben Woodhall On 3 Sep 2015, at 21:38, Elvis Au wrote: <blockquote> I reached out to nuke support and it sounds like something similar was fixed in 6.2v4 (bug#16881) but may have resurfaced. But to confirm I'm sending them code samples. I can replicate the tcl python code in the knobs of all nodes getting triggered whenever anything in the script is changed. (Today I noticed that typing in a backdrop note triggered the tcl python code with each keypress...) So even if my python was light and zippy, in a large script with thousands of nodes all trying to execute python code, the gui will lockup until it gets through it all. I don't want to go down the path of restructuring all our code quite yet until I get word of whether this is can be fixed or not. But I'm hoping to get this sorted out since it is painful to work like this. Also I tried this in Nuke 9.0v7/linux. ----- Original Message ----- From: "Michael Garrett" < [email protected] > To: "Nuke user discussion" < [email protected] > Sent: Thursday, September 3, 2015 12:37:00 PM Subject: Re: [Nuke-users] python expressions locking up the gui I'd say it's largely because of the evaluation of the python via tcl code in the knobs. As long as the functionality is retained, the code needs to be migrated from being constantly executed within the knob to being a module that loads the function once when Nuke starts up or when a node is generated - eg/ callbacks such as knobChanged, onCreate and onScriptLoad. I've been in this scenario before, and it is hellish trying to get any work done! But some cleanup of the python environment should make things a lot more zippy. Cheers, Michael On 26 August 2015 at 11:31, Elvis Au < [email protected] > wrote: <blockquote> Hey all - On particularly large nuke scripts, I'm seeing the scripts lock up for a few seconds before regaining interactivity in the gui. Digging into it, I found that we have a lot of python code (embedded in tcl eval code in knobs) which all seem to have to execute any time I make any update (add/remove a node, change a knob, attach/disconnect a noodle, etc) And on larger scripts, because there's more of this code that has to be run through so the lag feels worse. I can see the expressions fly past if I have the script editor open and when the it's done printing out, the script becomes responsive again. In a test, we removed the python expressions and everything is zippy again. But this seems excessive that all this code is triggered all the time when any change is made, upstream or downstream. Is there a rhyme or reason to this? Has anyone seen this before? Any insights? Also I'm 8.0v6/linux. thanks! Elvis _______________________________________________ Nuke-users mailing list [email protected] , http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users _______________________________________________ Nuke-users mailing list [email protected] , http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users _______________________________________________ Nuke-users mailing list [email protected] , http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users </blockquote> -- Ben Woodhall Software Engineer The Foundry Visionmongers Ltd 5 Golden Square London, W1F 9HT Tel: +44(0)20 7473 4350 Web: www.thefoundry.co.uk Email: [email protected] The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 </blockquote> <blockquote> _______________________________________________ Nuke-users mailing list [email protected] , http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users </blockquote> _______________________________________________ Nuke-users mailing list [email protected] , http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users </blockquote> -- Ben Woodhall Software Engineer The Foundry Visionmongers Ltd 5 Golden Square London, W1F 9HT Tel: +44(0)20 7473 4350 Web: www.thefoundry.co.uk Email: [email protected] The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 </blockquote> _______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
