Re: [Visualpython-users] Philosophical question

[David S. <dsc...@mi...>]

> > I'm curious why VPython is written as a C-extension, rather than on top of
> > pyOpenGL.  Is it strictly a performance thing?  Since pyOpenGL is already a
> > C-extension, the performance shouldn't be a problem, but that could be my
> > own ignorance speaking.  I'm mainly curious because the more an extension
> > relys on C the less portable it becomes, and as a pedagical tool I prefer
> > Python code to C code.

> It's a speed thing. The first couple of versions of Visual were written
> purely in Python, for ease of prototyping/modification. But when the interfaces
> were pretty well finalized, it was rewritten in C for speed. 

Yes.  Rendering a complex scene at 30 frames per second just takes a lot
of work, and OpenGL can only do part of it.  To make matters worse,
in order to provide a user-friendly interface Visual needs to do lots of
error checking that is usually omitted from graphics software.  The
Python implementation was *full* of __getattr__ hooks and so forth.
We do our own projection and lighting (usually provided by OpenGL) so that
we can maintain the double-precision floating point precision that Python
(and physics applications) expect.  It does rendering in the background,
which opens up a whole can of threads, I mean, can of worms :)

> That said, I don't see
> 
> a) why Python should be more portable than C. Python is written in C. 

Ari: If cvisual is so portable, why is the Linux version so far behind?

Portability should be measured in platforms/hour (over some broad 
reference set of platforms, of course). A typical Python program can be
"ported" to a platform that already runs Python in much less time than a
typical C program can.  There are lots of reasons for this; variation in
libraries is the strongest one.  Broadly accepted abstractions like OpenGL
are few and far between, and OpenGL alone can't even open a window.

I would say that the Visual prototype was as much as 10-100 times more
portable than cvisual by this measure.  However, it was also as much 
as 10-100 times slower!

> b) why it should matter "as a pedagogical tool" how Visual is implemented. If
> the internals were one extremely long PERL line, it shouldn't matter. The main
> thing is the friendly Python API.

A graphics system implemented in an open and friendly manner would be an
excellent tool for teaching the principles of graphics.  However, it
shouldn't try to implement Visual's semantics, which are hard!  I would
also suggest either a raytracer or a software scanline renderer (and
that is in fact what is usually done in graphics courses).

Dave