From: Bruce S. <Bru...@nc...> - 2009-07-20 17:55:27
|
I'm pretty swamped at the moment with finishing a textbook and can't give as good a response as I'd like, but I'll say very quickly that even being very careful to be as efficient as possible in C++ it's quite easy to get poor performance with VPython if you have lots of objects. What VPython does is quite difficult and time-critical. And a quick comment on pyGTK: Many cross-platform schemes were attempted, and none was found adequate for building Visual on Windows, Mac, and Linux. That doesn't mean that it's not possible, only that the developers did try and didn't succeed. Maybe someone else will step forward and make a big improvement. Bruce Sherwood Jim Thomas wrote: > I'm sure I'm not alone in wishing that VPython would integrate better > with our more full featured programs. The best technique I've come up > with so far is to put the visual code in a separate thread and use > queues to talk between my python based (GUI) program and the visual code > and it's standalone window. > > I've been perusing the source code to see if there is a way to get > visual to use a window I manage. It seems it might be possible by > rewriting display.cpp to use a passed GTK window handle/id to create the > display and eliminating gui_main. However I use wxPython which while > based on GTK on linux, it uses native libraries on other platforms. So > that is not a great solution for me. > > However there is a common denominator available with almost any decent > GUI library -- OpenGL. What I was thinking was this -- how critical is > it that the 'GUI' portion of visual be implemented in C++? From what I > can tell, 0% of Visual Python is actually implemented in Python. Why > couldn't all the GTK portion of the library be implemented in pyGTK? > Wouldn't that actually make development easier? In my experience Python > is up to 10x better from a development perspective. I didn't see > anything particularly performance critical in the GTK code side of > things, did I miss something? Implementing the library as a python GUI > + C++ OpenGL would make it possible to have alternate GUI front end > options such as wxPython, or an expert mode with no default windows > suitable for integrating with an existing GUI program. > > Has this been considered before and tossed out as non-feasible? Did I > overlook something critical in the source code? I have not spent lots > of time yet but I am up for trying to do a proof of concept if it is not > a known dead-end. The other thing I was considering is trying to do a > re-implementation in 100% python and then profiling to determine what > portions if any should be moved into C++. It seems to me that most of > my calls to visual are during the model definition phase where > performance is not really an issue. Outside of re-positioning / > re-orienting, relatively few functions are called every display loop. > Are the locations of the bottlenecks already known? Is this idea silly? > > I really like Visual Python from the point of view of ease of use of the > library. However there are serious limitations (perhaps unnecessarily > so) once you move beyond demo programs and I fear that at some point I > may be forced to 'graduate' to OpenGL. I would love to see Visual as an > easy way to start doing 3D (as it is now) and as your knowledge grows, > remove the training wheels and have a great way to do advanced things > as well. > > JT > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |