I see you've already decided against it, but let me take a min to
explain my own reasons why I think that this is a bad idea.
On Thu, 2006-06-08 at 11:36 +1000, Hugh Fisher wrote:
> Some thoughts regarding possible implementations of Visual
> Python on top of PyGL. (Scene graphs in the next message.)
>
> Implementing Visual Python on top of PyGL wouldn't get rid
> of all the C++ code. PyGL wraps the OpenGL API, but that
> doesn't cover window creation or keyboard/mouse handling.
This is no big deal - there are several OpenGL-capable windowing systems
out there, including PyGtkGLExt and WxPython.
> The big advantage I can see of using PyGL is that new
> graphical primitives could be written in Python and added
> at runtime, instead of the current requirement to write
> them in C++ and rebuild cvisual. As Jonathan points out,
> all the primitives in VP are static geometries
Several of them are not static, and must be frequently rebuilt. Arrows,
rings, and labels are prominent examples. Anytime the scene requires
high dynamic range (abs(pos) > 1e10 or < 1e-10 or so), significant extra
computation is required.
> so can be
> compiled into display lists. The overhead of OpenGL calls
> in Python rather than C++ would be minimal and I doubt
> anyone would notice.
IF you can crank everything into displaylists and/or vertex arrays, then
yes. However, this is not commonly the case, as above.
> Jonathan observed we could use GLUT for window, keyboard,
> and mouse handling. GLUT is simple, but it might be worth
> thinking about wxPython which is a cross platform GUI
> toolkit instead.
>
> Or, just leave the window management and event handling
> in C++ as done now.
The GUI code is the most amenable to implementing in Python. The
current 4.beta series is designed with this in mind. If you look, there
is a new class called a display_kernel. It implements everything needed
to run the Visual scene graph, without any GUI code. There are a
handful of hooks built in so that a GUI can be wrapped around (or
inherited from) this class.
> The major disadvantage is that it introduces a dependancy
> on another piece of software. One of the things that makes
> Visual Python great is that you download it and it Just
> Works. (Well, almost always.) Basing VP on PyGL means
> having to point users at another download site, or shipping
> a copy of PyGL with every copy of VP, or ... I'm sure it
> can be done, but is it worth the hassle?
Nah - this argument is a red herring. We already package a couple of
extra libs with Visual (such as Numeric and Numarray). 4.betaX includes
a 30 MB GTK runtime along with it.
However, doing all of the rendering in C++ offers one _huge_ advantage
over Python, that is independant of all other arguments. By running
the GUI/rendering thread in C++, rendering takes place concurrently with
physics code.
Python is not capable of concurrent threading. When a Python program is
mulithreaded, only one thread can ever run at any given time, regardless
of the threading support of the host. This is because the interpreter
itself is not thread safe. The interpreter multiplexes back and forth
by rapidly releasing and grabbing a global interpreter lock. Even on
multi-core and hyperthreading hardware, only _one_ Python thread can run
at any given time (within a single program, that is).
-Jonathan
|
