Menu
▾
▴
Re: [Visualpython-users] Not Enough Python in VPython?
|
From: Jim T. <jt...@mi...> - 2009-07-21 19:03:10
|
Thank you Bruce for such prompt answers. It sounds like I need to keep digging through the code and understand how it works better. David's link at an old attempt gives me some hope that it might work. JT Bruce Sherwood wrote: > I asked David Scherer for an expert response to this question. Here's > what he said: > > "The question is whether some or all of the platform-specific window > handling code could be written in Python. The answer to this question > is, I think, yes - as you may recall, I did some experimentation with > that myself (in the context of a Mac port, and of eventually supporting > visual widgets for windowing libraries). The performance effect is not > necessarily significant for the simple reason that things like display > and mouse handling only do O(1) work per frame, while the heavy lifting > is already in platform-independent C++. On the other hand, the > "productivity" benefit is not so clear either because the low level > platform-specific APIs for windowing are usually not exposed or > documented very well in Python, or are exposed only through optional > libraries that are heavy dependencies, or are wrapped in higher level > libraries that make some decisions inappropriate for Visual. I think > that, on balance, keeping the platform-specific code in C++ was the > right decision for the "big three" platforms, but this decision could > certainly be revisited in the future (especially for Linux, where > dependency hell is socially acceptable). More to the point, however, > Python display implementations could be an excellent way of supporting > edge cases like this one (displaying as part of a window managed by > another library). > > The Python display implementation I wrote is in the CVS history at > /vpython-core2/site-packages/visual/pyglet.py, with "show dead files": > > http://visualpython.cvs.sourceforge.net/viewvc/visualpython/vpython-core2/site-packages/visual/?hideattic=0 > > > It makes a display window based on the pyglet library. It probably > won't work unmodified because of various changes made to visual since I > stopped working on it, and I doubt it was ever full featured (e.g. no > keyboard support), but it would be a good starting point for anyone > experimenting in this area. I would think someone could develop a > wxwindows "visual widget" relatively easily, though there are surely > traps for the unwary." > > Bruce Sherwood > > P.S. If I remember correctly, this particular approach using pyglet was > abandoned in part because it didn't just immediately work on all platforms. > > 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 >> >> > > ------------------------------------------------------------------------------ > 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 > |
