Re: on profiling, multithreading, and file I/O.
On Thu, 27 Jan 2000, Paul Duran wrote: On Wed, Jan 26, 2000 at 11:34:00PM -0700, teunis wrote: [snip] Using a socketpair takes ~17000 milliseconds just to poll(..) to see if there's data. Is there a better way? I -need- to shave this ~17000 milliseconds off! 17000 milliseconds = 17 seconds... are you sure you dont mean microseconds? same for above and below?? Right, sorry. Read microseconds... *sigh* Sorry 'bout that. It's still slow. G'day, eh? :) - Teunis
Re: SGI OpenGL freely avalibale.
On Wed, Jan 26, 2000 at 04:42:38PM -0500, James A Simmons wrote: http://oss.sgi.com/projects/ogl-sample/ What's missing from the current Sample Implementation? Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow. Interesting, we came about the same technique as SGI: The GGL code in KGI-0.9 was a code-study how to dynamically generate i386 assembly code for software rasterization. Steffen - e-mail: [EMAIL PROTECTED] -
Windowmanager protocols
Hi all! I'm playing with the thought of writing a window manager based on ggi. Of course X Window programs should run also as well as programms with graphic libs based on X Window. As far as I know there are some communication functions in X where the window manager and the client are communicating about resize requests or when quiting the aplication. Is there something equivalently within GGI??? gr. matthias
fastest output
hi i want 8 bit 640x480 i create pictures. let'S say from my own handcoded 3D engine. it writes into a linear 8bit buffer. but it overwrites quite often. then i do some update function and want the picture on screen. until now i use directbuffers if possible. and ggi_putbox if not. but couldn't it be that ggi_putpox is faster ??? shouldn't i use ggi_putbox to write my internal buffer into the directbuffer ? is a directbuffer on the graphicscard behind the slow ISA bus or is it in RAM i mean. what is fastest solution ? cu erik -- Name: Erik Thiele Email: [EMAIL PROTECTED]o `QQ'_ IRC: erikyyy/ __8 WWW: http://www.erikyyy.de/ ' `
Re: SGI OpenGL freely avalibale.
On 2000/Jan/27, Steffen Seeger wrote: Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow. Interesting, we came about the same technique as SGI: The GGL code in KGI-0.9 was a code-study how to dynamically ^^^ What do you refer to with GGL? :) -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ] ^^^
Re: Windowmanager protocols
Hello, I have strong interests in a ggi related window manager. As for writting it in ggi I dont know. I am writting a couple of library sets that build on the ggi concept. The first liboui, prononced lib-we is a wrapper that targets other tool kits. I have a basic example written in python that creates a hello world program in gtk or tk. The end result is to target any display and use the appropriate window tool kit. The idea is further reaching than the wxWindows tool kit. Even targeting such diverse "display" evnviroments as the speach card for the blind and the non graphical consol. The second library liboctopus will be a high level tool kit that will use ggi as a display enviroment to be used with liboui. Programs written in both will be applications that can run on any enviroment with out recompiling that can also be changed dynamicaly while running. I have been planning to write a "catch all" manager that could help the applications under any enviroment. It would not be a ggi only window manager though as it would also be used on non graphic consoles and the speach target. It should also scale or step up through the modes and even merge different modes together. The first applications that I will be making are and ide and a package managment front end that will handel cross platform installs. I will be trying to obtain a place for a mail list and web portal soon and will put up the cvs stuff. :) On Thu, 27 Jan 2000, Mathias Weiss wrote: Hi all! I'm playing with the thought of writing a window manager based on ggi. Of course X Window programs should run also as well as programms with graphic libs based on X Window. As far as I know there are some communication functions in X where the window manager and the client are communicating about resize requests or when quiting the aplication. Is there something equivalently within GGI??? gr. matthias - Bryan Patrick Coleman [EMAIL PROTECTED] http://www.uncg.edu/~bpcolema Triad Linux Users Group Octagram Linux [EMAIL PROTECTED]
Line Clipping
Hi I found that standard GGI line clipping getting perpetual loop with some arguments. It was while using these arguments: 568, 383, 49360, and 1234 for clipping area 100, 3, 1019, 766. May be it was different because I found it written in my notebook but sure only for 90%. Anyway it was close enough. It happened because of overflow in line formula. Solution is: just break the perpetual loop. It's not necessary there. Also I found that Matrox G100 acceleration is slowly than software drawing. That's it. Best Regards, Dmitry Semenov EMail: [EMAIL PROTECTED] Web: www.chollian.net/~hatter -Original Message- From: Rubén [mailto:[EMAIL PROTECTED]] Sent: Friday, January 28, 2000 7:36 AM To: [EMAIL PROTECTED] Subject: Re: SGI OpenGL freely avalibale. On 2000/Jan/27, Steffen Seeger wrote: Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow. Interesting, we came about the same technique as SGI: The GGL code in KGI-0.9 was a code-study how to dynamically ^^^ What do you refer to with GGL? :) -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ] ^^^
Re: Windowmanager protocols
I'm playing with the thought of writing a window manager based on ggi. In what sense ? I.e. GGI is not a windowing system, so I don't quite see what to manage. Or do you mean something like writing an X windowmanager that does its rendering of decorations and stuff via LibGGI ? I have never thought about the latter. Is anyone with deeper insight into Windowmanagers here to tell us how it is done ? Is it basically like opening additional Windows cleverly placed around the application window, or drawing to the root window (I doubt that) or what ? 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. That wouldn't be exactly what GGI is designed for, but looking at the popularity of the screamingly colorful windowmanagers like WindowMaker or Enlightenment, it could give GGI quite a boost in interest. That is: If we can make a windowmanager that will run GGI applications to render his widgets, that would be way cool. I'd definitely volunteer to write a bunch of cool plugins, though I have no idea about how to write a windowmanager. Of course X Window programs should run also as well as programms with graphic libs based on X Window. O.K. - only chance I see then (except if you want to take the huge effort of writing a "Direct-X-through-GGI", i.e. kind of an X-wrapper like the SVGAlib wrapper is), would be what I propose above (though I don't know, if it is doable). As far as I know there are some communication functions in X where the window manager and the client are communicating about resize requests or when quiting the aplication. Yes. Is there something equivalently within GGI??? No, because GGI does not have such functionality. We had considered something like it for the resize stuff at least, but AFAIK it is not implemented. However there is libwmh that can be used to "remote-control" a windowmanager, if one exists. That is a LibGGI application can ask the windowmanager for placement, size, setting window titles, z-ordering and iconifying stuff. 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. 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 ... CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: dvi ps
On my outdated laptop, I use GS to create bit-map files, and a very basic anti-aliasing zooming PBM-viewer to display them (which I wrote). This is based on SVGALIB, so it should work under emulation with GGI (?right?). Probably. If it doesn't do anything nasty, the wrapper should work. The other thing about GhostScript is that it does some special things when directed to write to a window under X that it doesn't normally do for other drivers, like anti-aliasing. Hmm - I'd assume it will do the same on targets that can accomodate the output. pgm should suffice. A GGI-based GV-replacement will be on my wish-list too, I have just thought about this a bit, and here is what I came up with: 1. Writing a GGI driver for ghostscript isn't quite trivial, as we should add a little "feedback" like allowing the "return for next page" to come from the GGI visual instead of some maybe backgrounded terminal the thing was started from. If someone knows how to do this, he's very welcome. However: 2. Writing a GGI application that _drives_ a standard ghostscript and displays the results should be pretty much _trivial_ depending on how much extra functionality you want to have. I have looked at the output that is produced, if you output -sDEVICE=pgmraw to a pipe: It is a simple concatenation of pgms. Now if we write a very simple application that will run ghostscript in a pipe, feeding it with the files the app got in its command line arguments and catching the output and rendering it into a memory-visual, we are almost done. All we need then is a bit of input stuff that will allow to scroll around in the result and allow to change ghostscript parameters for rerunning ghostscript (e.g. for zooming). If we want color, we just render to ppmraw. The loader code is pretty generic, and I have code for loading p?m files, if someone needs it. I'd say the functions: scroll-left/-right/-up/-down next-page change-zoom-factor (+/-/explicit set) should be trivial and usually almost all that is needed. It might be nice, if we could "post-zoom" (operating on the already obtained picture) to allow to simply render at high resolution and still quickly get overview pages without rerunning ghostscript. Other stuff like manifying glasses, going backwards etc. would be a bit trickier, though there are simple but slow solutions using ghostscript. I suppose that gv solves these problems by making use of the document structure stuff, as it only works on those files ... so ... Anyone here to take that programming challenge ? As said, it's pretty trivial. I'd expect it to be well below 1000 lines of code, I'd estimate 200 or 300 for a first version that works nicely, without the really tricky stuff. If noone does, I will eventually do it, as I'd definitely like to view ps right from the commandline ... (and other stuff that can be filtered to ps, like pdf, dvi etc.) CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Gnuplot GGI driver
Hi! I'm almost finished with a simple GGI driver for Gnuplot (which will make Octave work with GGI, which is what I want in the end). I need some info, however: * How can I get the resolution of the visual? * How can I tell if I'm using the X11 device or not? Cheers, -- 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
Keyboard
Hi! While I don't get the answer to my last question :) I'm using the GGI target for Gnuplot in fixed resolution. It works perfectly with Gnuplot, but NOT with octave. Here's what happens: when Gnuplot ends the plot, I call ggiGetc to wait for the user. In gnuplot there's not a problem because the program waits for the plot to end. Octave, however, opens a pipe and starts gnuplot in the background. So when I plot, I can see the next prompt from Octave, the cursor and then the plot pops up. I can press anything, the plot will erase but the console won't go back to text mode. If I switch consoles forth and back, I see that octave has exited dumping core... Any clues? -- 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
one more info
by the way, the same scheme worked with the linux driver (SVGAlib), which calls vga_getch. Maybe it's a problem with the error message (can't open genkgi.o or something) making its way to the command-line? Anyway, the mode should switch back to text mode at least... -- 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
