Need advice on the design of my application

[hbd666]

I am writing a hull-wave simulator for the design of boat hulls as they
are affected by waves.
This application is composed of 2 main parts, the part that renders the
waves and its impact
on the hull, and a GUI that controls the hull shape, waves, and other
factors. The two parts
of the application will need to exchange data, for example, the GUI will
set the hull shape and
this will be displayed by the renderer. The renderer will show the waves
and it will tell the
GUI statistics about the waves as they are being animated. This
application will run on Windows.

The Renderer part of the application must be written in C because it needs
to do very fast
numerical calculations and requires the use of OpenGL and must render very
quickly. The GUI
part of the application will be wxPython.

The options for constructing the application that I have thought of are:
1) The wxPython part launches the Renderer on a thread, and the Renderer
is a DLL
(provided a DLL can display graphics).
2) The Renderer starts a thread where the Python interpreter is embedded,
which launches
wxPython.
3) The Renderer and the GUI are actually two separate applications that
communicate with each
other over a socket.

My last resort is Option 3 because communications can be a hassle.
Option 1 seems to be the easiest but will be very difficult to debug the
Renderer using my
IDE because it is a DLL, if a DLL can display graphics at all.
Option 2 seems to be the most feasible both in terms of debugging and
displaying graphics.

I have concerns about the Python GIL and how that will affect the way this
program will work.
The Renderer is going to be running a tight loop. The GUI under wxPython
also runs a main
loop internally, but has the ability to put function calls on a sort of
stack to be executed
without interrupting its main loop.

In my experience implementing Option 1 in another project, I know that
Python suspends
execution until the DLL function calls return, but I did not launch the
DLL on a thread.
I expect that if the DLL were launched on a thread, a function call into
the DLL will still
suspend Python. Maybe someone can tell me if this is true?

Option 2 is of most interest to me, but how shall I handle the Python GIL
when the Renderer
runs its main loop? Will the main loop be unaffected because Python
interpreter is embedded
in a thread?

 

[Miki Tebeka]

I'd say go with option 1. Pass the window handler (or DC) to the rendered thread.

To overcome the GIL problem, you can use Py_BEGIN_ALLOW_THREADS
(see http://docs.python.org/release/1.5.2/api/threads.html)

 

[Miki Tebeka]

I'd say go with option 1. Pass the window handler (or DC) to the rendered thread.

To overcome the GIL problem, you can use Py_BEGIN_ALLOW_THREADS
(see http://docs.python.org/release/1.5.2/api/threads.html)

 

[Eelco]

My first suggestion would be to keep the rendering in Python, if at
all feasible, and do only the actual simulation/computation in C.
Rasterizing a heightfield and rigid body plus some plash effects is
nothing that couldnt be done in PyOpenGL, or even something higher-
level like visvis or mayavi. (visvis would be my first suggestion)

I would run the simulation in a python subprocess that calls into the
C dll; that should give you at least one core fully focussed on your
computations, without competition/blocking from any other modules.

Marshalling the simulation data between subprocesses should be a small
performance hurdle relative to getting it on your GPU; either way, the
python subprocessing module makes it entirely painless.

And I would start with an implementation in numpy; probably, you will
be doing some fft's and/or boundary element stuff. This can all be
done fairly efficiently in numpy; at minimum it will give you a
reference implementation, and its not unlikely it will work well
enough that you dont even want to bother with the C implementation
anymore.