Re: SGI OpenGL freely avalibale.
On 2000/Jan/28, Steffen Seeger wrote: The GGL code in KGI-0.9 was a code-study how to dynamically ^^^ What do you refer to with GGL? :) This was meant to be a experimental Generalized GL implementation. In KGI? Is there something working for an S3 Virge card that I can test on my machine? It's development is currently halted due to lack of time on my part. (I know of Where can I found more documentation on this project? the GGL Project, so I will probably have to choose another 3-letter word.) Well, it would be very difficult to convince GGL guys to change our name, only to convince them to change the logo was very very difficult (before we had a penguin taken from the GGI page and all the people confused it with a crow :)) -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: Line Clipping
On 2000/Jan/28, Dmitry Semenov wrote: Also I found that Matrox G100 acceleration is slowly than software drawing. It's impossible! On my machine the S3 Virge acceleration is _always_ faster than software drawing, even taking into account that it means lots of ioctl's on /dev/fb. I have an PII 333 MHz. And AFAIK S3 Virge is much slower than Matrox G100, maybe I'm wrong? -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: Windowmanager protocols
In what sense ? I.e. GGI is not a windowing system, so I don't quite see what to manage. GGI should draw the windowframes, buttons, icons or the background (root window). O.k. - I think that should be doable, however ... see below. Or do you mean something like writing an X windowmanager that does its rendering of decorations and stuff via LibGGI ? The basic idea is to start from concepts of known smart/small window managers like blackbox or sapphire. That means it should take care of placing window within the screen, resizing, closing, iconifying, fullscreen windows or the visability hirarchy. O.K. Is it basically like opening additional Windows cleverly placed around the application window, or drawing to the root window (I doubt that) or what ? Placing windows within an application window should be realized by a graphic toolkit, No - what I am talking about, is how the windowmanager places its decorations _outside_ the application window. I mean: If we can tweak the X target to render to such stuff, we could do way cool stuff like program icons running your favorite GGI program or titlebars and menus being interactive. Yeah, why not. But why should X render it? See below ... Of course X Window programs should run also as well as programms with graphic libs based on X Window. I guess this is the jumping point, if we have an application using e.g. Qt, it will need a running X Server. My imagionary window manager would run preferably with kgicon, so we'll get in trouble here. But a way out of it is to drop the X - server in the system completely and link Qt, gtk+ or what ever to XGGI. XGGI would need to map the XSetWM*, XMoveWindow, etc. to GGI functions or maybe to a external library. XGGI _is_ an X server. Nothing special about it. Moreover, if you want to do what I propose above, that does not require any such functionality. It would basically mean taking any existing windowmanager and ripping off the widget rendering parts and replacing them with calls to ggi applications. This would require a running X server what I don't want to. If you want to bypass the X server, I see only a single possible method: You have to make kind of an LibX11-wrapper. However you should be aware that this is a huge task. Even when stripping all the extension and undocumented stuff off, I count 523 functions exported by libX11.so here. Total is over 1200 ... Might be a bit ressource-intensive as it will eventually spawn off lots of processes, but most of them should sleep in the normal case anyway ... This is exactly what I don't want. A major reason why I want to use GGI for this win. manager is that X is a resource killer. Then this is the only way. All X applications talk to libX11, which in turn talks to the x server. The only place where you can intercept the communications before it gets transformed into X protocol requests (interpreting them would mean reinventing an X server), would be to replace LibX11. Doable, but very much work. The simpler approach would be to use a normal windowmanager, that happens to use LibGGI to draw its own widgets. That is, it would directly talk to X as usual, but after it has created the windows for its widgets, it will run LibGGI plugins to draw on them. This still requires an X server, but we can do quite some cool stuff in the decorations, and : I want a smart, fast, stable system. All instabilitys in the linux boxes I'm using comes form X, Regarding instability and ressource consumption, XGGI should help a great deal. It is very lightweight and 100% stable for me. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: Windowmanager protocols
Andreas Beck [EMAIL PROTECTED] writes: This is exactly what I don't want. A major reason why I want to use GGI for this win. manager is that X is a resource killer. Then this is the only way. All X applications talk to libX11, which in turn talks to the x server. The only place where you can intercept the communications before it gets transformed into X protocol requests (interpreting them would mean reinventing an X server), would be to replace LibX11. Doable, but very much work. Afraid not. Quite a few programs talk the raw X-protocol. All programs I wrote before GTK+ emerged did that. This is due to the fact that libX11 is actually not easier to use that the protocol directly and the fact that it (the lib) wasn't thread-safe at the time. -- Peter Bortas http://peter.bortas.org Idonex AB http://www.idonex.com
Re: Windowmanager protocols
On 30 Jan 2000, Peter Bortas wrote: Andreas Beck [EMAIL PROTECTED] writes: This is exactly what I don't want. A major reason why I want to use GGI for this win. manager is that X is a resource killer. Then this is the only way. All X applications talk to libX11, which in turn talks to the x server. The only place where you can intercept the communications before it gets transformed into X protocol requests (interpreting them would mean reinventing an X server), would be to replace LibX11. Doable, but very much work. Afraid not. Quite a few programs talk the raw X-protocol. All programs I wrote before GTK+ emerged did that. This is due to the fact that libX11 is actually not easier to use that the protocol directly and the fact that it (the lib) wasn't thread-safe at the time. Yah know, that explains why my very-multithreaded QT/[broken]mpeg2 player crashes with various faults under X. using GGI for display. Suggestions? :) G'day, eh? :) - Teunis PS: anyone who suggests SYSV stuff should tell me how I should wait for conditions with SYSV items. The shared-mem is not a problem, but the conditions are. Mind you I might just be clueless as it's been years since I last did SYSV stuff.
GGI extreme blues : NEED HELP
Well people, here's the situation: * I have a gnuplot driver that works in X but fails when in console mode. * I hacked dvgt, so that now *I CAN SEE DVI FILES WITH GGI*. It works in X, but then again, IT DOESN'T WORK IN THE CONSOLE!!! And that, of course, is what I wanted the dvi viewer for. HELP! I believe the error comes from the error message (unable to open shared library genkgi.o) that is sent to the console and garbles everything. But I can't be sure. And I don't have time! Can any kind soul get the sources for dvgt I hacked and figure out how to make things work in the console? Every time I try to use it in the console the *computer hangs for good*, while in X it works flawlessly... For someone proficient in GGI it should be a simple matter to either fix the problem or declare it without solution (which would be REALLY bad for GGI). Having a dvi viewer would be a real plus! Anyone up to the task??? -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,/'_ ,/'_ ,/'_ ,/'_ ,/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
