|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Fri Nov 09 2001 - 10:55:13 EST
Dear Erwin (and Magic developers, please read below the dotted line), > when I use "magic -dOGL" I get the beautifully blended colors, but the > pointer shape does not change when switching tools (e.g. box to wiring). Unfortunately, you're getting an error I can't reproduce. This is probably an X-Server problem. It is unexpected, as the OpenGL implementation relies heavily on X11 calls for just about everything besides rendering, so GrOGLSetCursor() and GrX11SetCursor() are virtually identical. > I can't run in 8-bit mode because my desktop needs at least 24-bits > for beauty and to impress the collegues who all run Windows. I have a Permedia-3 card, which has an "8-bit overlay" mode. Essentially, this means that if I use 32-bit graphics and set the "overlay" option in the X server's option file, then applications which want 24-bit visuals get the, but applications which want 8-bit visuals can get them, too. Check if any of your NVIDIA cards support 8-bit overlays. > Also, the redraw speed for either X11 or OpenGL driver is fairly slow > for large chips That's video-card dependent. My Permedia-3 renders at about 3/4 the rate of the purely-X11 display. What kind of slowdown do you see? Maybe we should get video card manufacturers to use magic and a large chip layout for a benchmark test. . . > I am wondering if "double-buffering" the graphics output would help? The output is double-buffered to the extent that is reasonable to do. Large chips do take time to render, and the response lag is unreasonable if rendering is done completely on the back buffer. Magic's solution is to render on the top buffer and allow Ctrl-C interrupts so that the user can move around the layout without waiting for a complete redraw. ------------------------------------------------------------------------ > Is anyone working on moving magic to a state of the art toolkit > such as Qt? MicroMagic (www.micromagic.com) has done just that, although they have taken advantage of the Berkeley (i.e., non-GNU) license on magic to produce and sell a proprietary version. It is not a terribly difficult thing to do, and because it presumably would link to dynamic libraries, such an interface can fairly easily be made to 1) be turned on or off by command-line option, and 2) not weigh down the executable with lots of extra code, and not require the overhead in memory if the option is turned off. The several times I have mumbled something about a real GUI on top of magic, I have proposed a method similar to that used by GhostScript <--> Ghostview. Ghostscript, like magic, has a simple interface. It will allow its top-level instantiation in the Window Manager to be superceded by a calling program (namely, Ghostview), which is then responsible for framing the window and capturing X11 calls. Magic and XHelper7 (formerly known as X11Helper) do the same thing, except that in its current instantiation, XHelper7 captures X11 calls but does not attempt to map the "magic" window(s) itself. If it did, it could implement its own menu system to complement the text-entry terminal interface to magic, or even redirect that function to another window or pane. I don't think Qt is a terribly good choice. I'd stick with a very simple widget set which does not attempt to redefine all the painting operations and X11 calls into its own syntax. > Also, I am wondering if Jeff Solomon's work will ultimately be > incorporated into "magic" as he seemed to have solved the speed > problem (see his DAC paper and presentation at > http://videos.dac.com/videos/38th/31/31_2/index.htm You'd have to ask Jeff. The problem is that in "solving" the speed problem he gutted magic to its bare essentials and then optimized what was left up the wazoo for a graphics card with lots of bells and whistles. Incorporating that into magic without disabling any of the exisiting functionality would be a full-time project. > The pinnacle of achievement would be to also get Python to work as a > scripting language as it is more straightfoward for most people than > scheme. I would also like to tackle that using "swig" ( a program which > creates bindings of C programs for Perl, Python, etc.), and would like > to know whether anyone is already working on that. That's a topic I'd like to take up some day with Rajit. I don't like writing in LISP, myself, and I have also had success integrating Python into XCircuit, which proved to be easier than I thought. Perl would probably be a good choice, too. I don't know if it is possible to set up the interpreter like the graphics, where one can compile with a choice of several and choose which one to use at run-time. I wouldn't tackle it with "SWIG", though. Some caution is required to make sure that SCHEME and Python can be interchanged smoothly. One problem with Python (and SCHEME, too) is that it does not come as a dynamically- linked library. I was able to create a libpython.so on my Linux system, but it was not trivial. A few Python calls will increase the size of the executable by 3 or 4 MB, and it hogs memory like crazy (even with automatic garbage collection). These are all important issues that may very well affect the "survivability" of magic against competing programs over the next several years. I'd like to hear more from the other magic developers on whether we should start some long-term development to address these issues. Regards, Tim
|
|
|
|