CODEWITHSUNDEEP
pythonmultithreadingwxpythonbackground
Ram Rachum
Ram Rachum

Reputation: 88718

Python/wxPython: Doing work continuously in the background

I'm making a program for running simulations in Python, with a wxPython interface. In the program, you can create a simulation, and the program renders (=calculates) it for you. Rendering can be very time-consuming sometimes.

When the user starts a simulation, and defines an initial state, I want the program to render the simulation continuously in the background, while the user may be doing different things in the program. Sort of like a YouTube-style bar that fills up: You can play the simulation only up to the point that was rendered.

How should I run the rendering function?

Upvotes: 16

Views: 7786

Answers (4)

John Montgomery
John Montgomery

Reputation: 9058

There's a fair bit of info on the wxPython wiki about long running tasks that might be useful. They basically make use a thread and wx.PostEvent to handle communication between the thread and the main wx event loop.

Upvotes: 7

attwad
attwad

Reputation: 945

If you don't mind using a very slightly different approach, you can have a look at stackless python and create a tasklet for your rendering process. I find it very easy to use personally.

Upvotes: 0

FogleBird
FogleBird

Reputation: 76862

I would use a threading.Thread to run the code in the background and wx.CallAfter to post updates to my window thread to render them to the user.

thread = threading.Thread(target=self.do_work)
thread.setDaemon(True)
thread.start()

...

def do_work(self):
    # processing code here
    while processing:
        # do stuff
        wx.CallAfter(self.update_view, args, kwargs)

def update_view(self, args):
    # do stuff with args
    # since wx.CallAfter was used, it's safe to do GUI stuff here

Upvotes: 11

Chris Upchurch
Chris Upchurch

Reputation: 15537

Launch a new process to render in background and periodically check to see if it has returned.

You can find the documentation for the subprocess module here and the multiprocess module here. As Jay said, multiprocess is probably better if you're using Python 2.6. That said, I don't think there would be any performance difference between the two. Multiprocess just seems to be a wrapper around subprocess making certain things easier to do.

While subprocess/multiprocess is the standard way to do this, you may also want to take a look at Parallel Python.

Upvotes: 4

Related Questions