Michiel de Hoon
mdehoon at c2b2.columbia.edu
Thu Sep 6 11:57:25 BST 2007
Martin Teichmann wrote:
> Now, one could ask, why am I doing such a stupid thing as calling
> raw_input from within a different thread? Well, I just had tried to solve
> exactly theproblem PyOS_InputHook was made for: to be able to
> type commands on the commandline while the GUI is running at the
> same time. I just did that using a different thread, which, in my
> humble opinion, is a slightly better idea than the hook. I am not
> alone: ipython (and pylab) do the very same, on their mailing list
> someone already posted the problem.
I was just wondering: In your approach, can you avoid the performance
loss caused by using a different thread?
In the approach using PyOS_InputHook (which is what Tkinter uses), the
GUI event loop and Python run in the same thread. If Python is busy
doing other stuff, the event loop is not running and the GUI is not updated.
In the approach using threads, the GUI is updated continuously, whether
Python is busy with other things or not. But for heavy drawing, that is
not what you want. In particular, if you have many individual PyQT
drawing commands to create a complicated figure, redrawing after each
individual drawing command will lead to duplicated drawing events,
causing a huge slowdown (I can give you an example for pylab, if you're
interested). Using PyOS_InputHook will guarantee that drawing is done
only when all the information needed for the drawing is available.
Ideally, I would like to see a solution where the GUI is running in a
separate thread, but drawing is done only when the Python-thread reaches
the PyOS_InputHook point in the code. Can your approach do that?
More information about the PyQt