Re: Python-visual in latest Ubuntu

If some people do get serious about redoing VPython, here's something
to keep in mind. I believe that one of the reasons why very few people
have made substantive contributions to VPython development is that it
involves multithreaded C++ and must work on all platforms, all of
which requires uncommon expertise (and some fearlessness). Compare
with the GlowScript project (JavaScript + WebGL instead of Python +
OpenGL; see glowscript.org).

Basically, JavaScript doesn't have threads (ignore the special and
strictly limited "worker" thread for purposes of this discussion). If
you write an infinite loop in JavaScript, nothing can break into that
loop, and your web page is hung forever. In VPython the render thread
interrupts your Python calculations, and there are complex issues
associated with having more than one thread.

In GlowScript, this strategy is literally impossible to implement.
Rather, your program MUST be organized into chunks that are called at
times you specify. GlowScript uses the Streamline library to chop up
your VPython-like program into such chunks; for example, a rate(50)
statement in a loop causes GlowScript/Streamline to compile the loop
contents into a separate routine that is driven 50 times a second. One
of the timer-driven chunks is the render routine, which runs about 30
times a second, similar to VPython, but it's not a thread, it's just
one of the many timer-driven short routines.

One consequence is that in GlowScript, if you execute a lengthy piece
of code to set up a complex 3D scene, you know that the scene will be
completely defined and appear all at once when you execute that code
and the render routine gets a chance to run (the render routine may
have been delayed for much more than 1/30 second but will run
immediately when other activity has ceased). In contrast, in VPython
the render thread will break into your scene creation and display a
partial, incomplete scene unless you make the scene invisible until
you're finished with creating the scene.

Even though the Python environment permits threading, it's worth
considering a GlowScript-like strategy, simply to avoid the
complexities of multithreading and thereby reduce the barriers to
people making contributions to the core code.

An important issue to bear in mind is that one would like the look and
feel to be native on all platforms, but I repeat that there's a
serious problem on the Mac, in that we didn't find a way to base
VPython on Cocoa due to threading issues, and Carbon is deprecated and
doesn't run with 64-bit programs. If the threading issues go away,
maybe the Mac issue could also go away.

Another thing to keep in mind is that in 2000 few people had graphics
cards with powerful GPUs, whereas a new "VPython" presumably should
require such cards and be built from the start to exploit them.

I agree with Aaron that the most important feature of VPython is its
API, not the particular implementation. If some of you see a better
way to implement that API, go for it! And if you do go for it, do pay
attention to GlowScript development, whose API is very similar to but
not identical to VPython, and I think the (relatively minor) changes
are good ones.

I would be very willing to help anyone interested in rebuilding
VPython by providing explanations of the existing code, though I
confess that there are some aspects that I don't fully understand. On
the other hand, the current code may be mostly irrelevant; it's the
API that defines what needs to be done.

Bruce Sherwood

On Tue, Dec 6, 2011 at 1:19 PM, Aaron Mavrinac <[email protected]> wrote:
> James/Bruce,
>
> If there is a serious attempt made at migrating Visual onto a pure
> Python graphics back-end, I'd definitely be interested in joining that
> project. The Python API for Visual is brilliant and the graphics are
> fast, but the nature of the current implementation imposes several
> limitations (notably, GTK+ event loop issues and some disconnects in
> display and object interaction) that might be easier to address -- and
> failing that, for users to monkey-patch their way around -- if it were
> pure Python. This is, of course, in addition to the aforementioned.
>
> On a related note, there seems to be much demand for a good native 3D
> geometry library in pure Python [1]. If the above were to happen, it
> might make sense to spin off a separate efficient geometry library at
> the same time (something in which I'd be even more interested in
> participating).
>
> [1] http://stackoverflow.com/questions/1076778/good-geometry-library-in-python
>
> --
> Aaron Mavrinac
> www.mavrinac.com

------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/