From: Bruce S. <Bru...@nc...> - 2011-12-06 22:12:40
|
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 <mav...@gm...> 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 |