Menu
▾
▴
Re: [Visualpython-users] Not Enough Python in VPython?
|
From: Michele M. <mat...@gm...> - 2009-07-23 14:56:09
|
I think there is the need to be able to use visual as a widget for any toolkit. In my specific case I'm using a GTK GUI, but as Jim as written, I'm able to detect an input an process the return value only if I leave the main thread of the gtk gui and enter a while loop, until I return the value back and get back into the main gtk loop. This of course cause a lot of busy waiting, consuming the CPU and offering a bad user experience. If I understood correctly this was done before somehow... Is that true? On Tue, Jul 21, 2009 at 9:02 PM, Jim Thomas<jt...@mi...> wrote: > 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 >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
