e.g. ...
class MyClass(object):
def __init__(self):
self.progress = nuke.ProgressTask('progress')
self.progress.setProgress(100)
P = MyClass()
# Clean it up
del(P.progress)
On Mon, Jul 28, 2014 at 7:53 PM, Nathan Rusch <nathan_ru...@hotmail.com>
wrote:
> The progress bar will stay alive as long as there is a Python reference
> to it somewhere. It would be nice if the ProgressTask class had a method to
> close and clean it up, but in the interim, you just need to make sure that
> you're cleaning up references as necessary. You could also pass a weakref
> to the ProgressTask around (into nested functions, etc.), in which case you
> would just need to make sure the top-level code didn't clean it up too
> early.
>
> -Nathan
>
>
> *From:* Richard Bobo <richb...@mac.com>
> *Sent:* Monday, July 28, 2014 11:16 AM
> *To:* Nuke Python discussion <nuke-python@support.thefoundry.co.uk>
> *Subject:* Re: [Nuke-python] Running heavy code in separatethread
> withprogressbar
>
> Hey Nathan,
>
> ...Just following the (mail)thread and I was wondering how to get the
> progress bar to close when the count finishes? I have tried a number of
> things and the progress bar remains on screen, either stuck at 99% or 100%,
> depending on what I do to check for the count to be finished. Is there a
> close method or something that needs to be done to make the window go away…?
>
> Thanks,
> Rich
>
> Rich Bobo
> Senior VFX Compositor
> Armstrong White
> Email: rich.b...@armstrong-white.com
> http://armstrong-white.com/
>
> Email: richb...@mac.com
> Mobile: (248) 840-2665
> Web: http://richbobo.com/
>
> "The most beautiful thing we can experience is the mysterious. It is the
> source of all true art and science."
> - Albert Einstein (1879 - 1955)
>
>
>
>
>
> On Jul 28, 2014, at 2:07 PM, Nathan Rusch <nathan_ru...@hotmail.com>
> wrote:
>
> That first paragraph was poorly-worded. What I meant to say is
> "nuke.executeInMainThreadWithResult is going to impose a performance hit on
> your sample code due to thread juggling, since each switch requires the
> running Python thread to grab the GIL."
>
> -Nathan
>
>
> *From:* Nathan Rusch <nathan_ru...@hotmail.com>
> *Sent:* Monday, July 28, 2014 10:11 AM
> *To:* Nuke Python discussion <nuke-python@support.thefoundry.co.uk>
> *Subject:* Re: [Nuke-python] Running heavy code in separate thread
> withprogressbar
>
> No, it doesn't create a thread. However,
> nuke.executeInMainThreadWithResult is going to impose a performance hit,
> since your sample code is juggling threads, and each switch requires the
> running Python thread to grab the GIL.
>
> I think what Dan was getting at is that you should refactor your code so
> the callable you pass to executeInMainThread does its own looping
> internally, to cut down on thread switching in Python. Also, you should
> only use executeInMainThreadWithResult if you actually need the result from
> the main thread call; use executeInMainThread otherwise. Finally, make sure
> to create your nodes without control panels.
>
> This runs in a little over a second:
>
> def createBlurs(count, progressTask):
> for i in xrange(count):
> nuke.createNode('Blur', inpanel=False)
> progressTask.setProgress(i / 10)
>
> def threadCallable():
> task = nuke.ProgressTask('Create')
> task.setMessage('Creating blur nodes')
> nuke.executeInMainThread(createBlurs, args=(1000, task))
>
> threading.Thread(target=threadCallable).start()
>
> -Nathan
>
>
> *From:* Bram Buddingh <b...@postoffice.nl>
> *Sent:* Monday, July 28, 2014 8:40 AM
> *To:* Nuke Python discussion <nuke-python@support.thefoundry.co.uk>
> *Subject:* Re: [Nuke-python] Running heavy code in separate thread with
> progressbar
>
> Ah! It looks like that is working…haha.
>
> So, each time I run the code ‘nuke.executeInMainThreadWithResult’ Nuke is
> starting a thread? I thought it only executes a piece of code in the main
> thread and that you call a new threat with 'threading.Thread(None, ‘
> *function*').start()’.
>
> Thanks!
> Bram
>
>
> On Jul 28, 2014, at 4:19 PM, Dan Rosen wrote:
>
> Try the for loop inside the thread rather than a thread for each time it
> loops. Maybe?
>
> On Jul 28, 2014, at 5:57 AM, Bram Buddingh <b...@postoffice.nl> wrote:
>
> Hi everybody,
>
> I am working on a python script that creates more than 25 read nodes with
> approximately 30 timeOffset nodes connected to each of them. So I end up
> with a script containing something like 1000 nodes. This could be extended
> later, depending on the needs.
>
> This is quite compute intensive to run. The main nuke thread/window
> freezes and you don’t know how long you have to wait until it’s finished. I
> am trying to put this in a separate thread with a status bar. The problem
> is that the threaded way is even slower than without putting it in a
> separate thread. To make it a bit clear, I wrote some python lines to
> demonstrate what I am trying to do:
>
>
>
> --------------------------------------------------------------------------------------------
> import threading
>
> ### option 1: even slower than option 2 ###
> def createBlurNodes():
> task = nuke.ProgressTask("Create")
> task.setMessage("Creating blur nodes")
>
> for i in range(1000):
> nuke.executeInMainThreadWithResult(nuke.createNode, args = ('Blur',
> '', False))
> task.setProgress(i/10)
>
> threading.Thread(None, createBlurNodes).start()
>
>
> ### option 2: slow and I don't have visible feedback about the estimated
> calculation time. Plus nuke is freezing for a couple of seconds, depending
> on your machine specs. ###
> for i in range(1000):
> nuke.createNode('Blur', '', False)
>
>
> --------------------------------------------------------------------------------------------
>
> Maybe it’s slow because nuke.createNode is always running in the main
> thread?
>
> Is this the correct way, or is there a better way to script this?
> Thanks for the help in advance!
>
> Bram Buddingh_______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
> ------------------------------
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
> ------------------------------
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
> ------------------------------
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
--
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
