zombie@voodoo.UUCP (Mike York) (08/29/90)
We're looking in the crystal ball and trying to identify hardware and software
costs for the next year. What's not clear to us is SGI's migration plan to X.
Is there one? Will we have to buy the X Window Development System at $950
a pop for all of our PI's or will it come with the Software Development
Package? Will we have to buy it for our 320S?
Anyone at SGI care to comment? This whole area is very fuzzy right now...
--
Mike York | "I want to embrace you, but
Boeing Computer Services | first, I have to satisfy
(206) 234-7724 | my sense of moral outrage"
zombie@voodoo.com | -Roger Rabbitslehar@bucasd.bu.edu (Steve Lehar) (08/31/90)
Having worked with both SGI and X, I've gotta say that the SGI windowing and graphics system is the most beautiful, simple, well written, easy-to-use and elegant windowing system I have ever had the pleasure to work with! You look it up in the manual, type it in, and HEY PRESTO! it works just as advertised! Now X is a whole nuther matter! The system is impossibly complicated, the documentation is obscure, and nothing ever works without sending email to the x consortium gurus themselves! Just as an example- I wanted to write values 0 to 255 into an 8 bit color map for image processing. Sounds simple? Well, just to get the window to appear on the screen takes a couple of pages of hyroglyphic code, but it always comes up coal black, I cannot seem to get anything in to the color map except 0,0,0,0,0,0... Finally, in exasperation I email to the gurus. "Oh yeah, we forgot to mention in the documentation, you have to left-shift the values by 8 bits because the color map only uses bits 9-16 in an 8-bit color map!" So to load a value 10, you load 10<<8! Why? Oh you see, some machines have more than 8 bit color maps, so it's for compatability- although that hasn't been implemented yet, so there IS no compatibility, only confusion. Another example- they provide an image structure for use with image processing, which works fine, and they supply routines for quickly displaying such images and performing graphics in them like drawing colored boxes and circles. The trouble is that if you want to do image processing you have to get your image data into that structure, and the only routine they provide sends the pixels over one by one, OVER THE NETWORK! so that even when you display from your own private terminal to your own private screen it goes... "Prepare to receive pixel", "sending pixel", "confirm receipt of pixel", "prepare for next pixel"... and so forth and of course it takes an eternity to send a whole image! I sent off to the gurus again and got a reply that I am still trying to implement after two months. In the meantime I put up with a system where it is quicker to process my image than it is to display the result on the screen! And then there are other little annoying things- like you cannot tell X in advance where you want your window to arrive, the only way to position it is by hand with the mouse. So I type in "display image A, B and C" and off it goes sending pixels one by one while I go to work on something else, but just as SOON as it's ready it interrupts me in the middle of my keystroke- suddenly the terminal will not respond to anything at all except the positioning of image A. Then as I get back to my typing I am interrupted again by image B and then image C. (and they don't necessarily come up in that order) Now I know that X is designed to run on any hardware, which is why it is so complicated, while the SGI stuff only runs on SGI, and that is why it is so simple and elegant. Nevertheless, I think SGI did an EXCEPTIONAL job in their graphics software, and I would not hurry on over to X unless I were absolutely FORCED to do so! X is messy, inordinately complicated, atrociously documented and unreliable. (My X image windows are prone to suddenly disappearing if they've been around for a while) My advice is to stick with SGI! -- (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O) (O)((O))((( slehar@bucasb.bu.edu )))((O))(O) (O)((O))((( Steve Lehar Boston University Boston MA )))((O))(O) (O)((O))((( (617) 424-7035 (H) (617) 353-6425 (W) )))((O))(O) (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)
drw900@anusf.anu.edu.au ("Drew R Whitehouse") (08/31/90)
In article <SLEHAR.90Aug30173222@bucasd.bu.edu>, slehar@bucasd.bu.edu (Steve Lehar) writes: |> ........stuff deleted..... |> Now I know that X is designed to run on any hardware, which is why it |> is so complicated, while the SGI stuff only runs on SGI, and that is |> why it is so simple and elegant. Nevertheless, I think SGI did an |> EXCEPTIONAL job in their graphics software, and I would not hurry on |> over to X unless I were absolutely FORCED to do so! X is messy, |> inordinately complicated, atrociously documented and unreliable. (My X |> image windows are prone to suddenly disappearing if they've been |> around for a while) My advice is to stick with SGI! I work in a multi vendor environment and can't wait for SG to go to X. Not to mention the fact that there is LOTS of good public domain software written for X windows(something you can't say about SGI's NeWS). And I like the window managers you get with X eg vtwm. I'm still stuck with the 3.2 X server since the Australian branch won't give us 3.3 yet, and it's driving me around the bend. So full speed ahead on the migration to X. -- /*---------------------------------------------------------------------- ------*/ /* Drew Whitehouse, E-mail: drw900@anusf.anu.edu.au */ /* Visualization Programmer, Fax : (06) 2473425 */ /* Australian National University, Phone : (06) 2495985 */ /* Supercomputer Facility. */ /* GPO Box 4, Canberra ACT Australia 2601. */ /*---------------------------------------------------------------------- ------*/
moraes@cs.toronto.edu (Mark Moraes) (08/31/90)
>and the only routine they provide sends the pixels over one by one, >OVER THE NETWORK! so that even when you display from your own private >terminal to your own private screen it goes... Not true. You can build and send the entire image in one go. See XPutImage. >And then there are other little annoying things- like you cannot tell >X in advance where you want your window to arrive, the only way to >position it is by hand with the mouse. Also not true. You can specify where you want the window to go. At the application level, most applications will accept the -geometry option -- at the program level, see XSetWMNormalHints. The X manuals are, um, terse. They're reference manuals. There are several tutorial manuals on the market now. You may find reading those manuals quicker than asking the people at the X Consortium. From the X Bibliography Ken Lee posts periodically to comp.windows.x, my favourites are: | Jones, Oliver, Introduction to the X Window System, Prentice-Hall, 1988. | ISBN 0-13-499997-5. An excellent introduction to programming with | Xlib. Written with the programmer in mind, this book includes many | practical tips that are not found anywhere else. This book is not as | broad as the O'Reilly Xlib tutorial and doesn't offer as many examples | as the Johnson & Reichard book, but Jones is probably the most experi- | enced X programmer of this group and this shows in the quality and | depth of the material in the book. Originally written for X11R1, re- | cent printings have included corrections and additions. The sixth | printing may have X11R4 material. | | Young, Douglas A., X Window Systems Programming and Applications With Xt, | Prentice-Hall, 1989. ISBN 0-13-972167-3. The first, and still one of | the best, tutorial on programming with the X Toolkit intrinsics. Both | using existing widgets and writing your own widgets are covered. Exam- | ples in this book use the HP widget set, available in the contrib sec- | tion of the X distribution. A Motif version of this book is also | available. Mark.
slehar@cochlea.bu.edu (Steve Lehar) (08/31/90)
When I complain that XImages must be transmitted pixel by pixel you say... ||> Not true. You can build and send the entire image in one go. See ||> XPutImage. Yes, you can send the image to the screen with XPutImage(), but how do you get your array of image data INTO the XImage BEFORE you send it to the screen? XPutPixel() is the only routine provided! And when I complain that I can't specify the X window position from my code, you say... ||> Also not true. You can specify where you want the window to go. ||> At the application level, most applications will accept the ||> -geometry option -- at the program level, see XSetWMNormalHints. Yes they do, but what about if I am WRITING the application? I can make my program receive the -geometry flag (or reasonable facsimile) but what do I DO with that information? When I open my XWindow I use the call win = XCreateWindow(display, RootWindow(display, screen), xsh.x, xsh.y, xsh.width, xsh.height, bw, vTemplate.depth, InputOutput, visual, valuemask, &attrib); Note that there is no argument for x and y screen location! How do I tell this XWindow where to appear? -- (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O) (O)((O))((( slehar@bucasb.bu.edu )))((O))(O) (O)((O))((( Steve Lehar Boston University Boston MA )))((O))(O) (O)((O))((( (617) 424-7035 (H) (617) 353-6425 (W) )))((O))(O) (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)
moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) (08/31/90)
In article <SLEHAR.90Aug30173222@bucasd.bu.edu>, slehar@bucasd.bu.edu (Steve Lehar) writes: |> Now I know that X is designed to run on any hardware, which is why it |> is so complicated, while the SGI stuff only runs on SGI, and that is |> why it is so simple and elegant. Nevertheless, I think SGI did an |> EXCEPTIONAL job in their graphics software, and I would not hurry on |> over to X unless I were absolutely FORCED to do so! X is messy, |> inordinately complicated, atrociously documented and unreliable. (My X |> image windows are prone to suddenly disappearing if they've been |> around for a while) My advice is to stick with SGI! I think that the perfect mix would be using a real X window manager like TWM, and to be able to run GL applications in an X window. X has a way to go to replace the GL for real graphics, but for the desktop environment, the availability and economy of using X is tough to beat. It sure would be nice to be able to run TWM on the SGI instead of customizing yet another window manager. Programming in X is not all that bad, PostScript is much more foreign to someone used to C programming. The accellerated development time provided by Xt toolkits is invaluable, and the volume of quality PD software is remarkable. The unreliability of X is a symptom of the server on the SGI (or wherever). I have never had windows disappear on my Sun (unless the process was killed, the network connection failed, etc.) and I find it very robust, but on the SGI, X just plain doesn't work worth a darn under 3.2.x. Hopefully 3.3 is much better. -Gary
moore%cdr.utah.edu@cs.utah.edu (Tim Moore) (08/31/90)
In article <SLEHAR.90Aug31102639@cochlea.bu.edu> slehar@cochlea.bu.edu (Steve Lehar) writes: > >When I complain that XImages must be transmitted pixel by pixel you say... > >||> Not true. You can build and send the entire image in one go. See >||> XPutImage. > >Yes, you can send the image to the screen with XPutImage(), but how do >you get your array of image data INTO the XImage BEFORE you send it to >the screen? XPutPixel() is the only routine provided! > That's what XPutPixel() does. It's a client-side operation; an image resides in the client's memory, so creating it doesn't involve any transactions with the server. There isn't any network traffic until you send the image to the server with XPutImage(). Just because a function has X in its name doesn't mean that it communicates with the server. >And when I complain that I can't specify the X window position from my >code, you say... > >||> Also not true. You can specify where you want the window to go. >||> At the application level, most applications will accept the >||> -geometry option -- at the program level, see XSetWMNormalHints. > >Yes they do, but what about if I am WRITING the application? I can >make my program receive the -geometry flag (or reasonable facsimile) >but what do I DO with that information? When I open my XWindow I use >the call Like the man said, see XSetWMNormalHints. > > win = XCreateWindow(display, RootWindow(display, screen), > xsh.x, xsh.y, xsh.width, xsh.height, > bw, vTemplate.depth, InputOutput, visual, > valuemask, &attrib); > >Note that there is no argument for x and y screen location! How do I >tell this XWindow where to appear? It is true that you can't specify with certainty where your window will end up on the screen. The rationale for this is that your window manager might have a different idea about where the newly created window should go. Hence, you give the window manager "hints". Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters
mikey@eukanuba.wpd.sgi.com (Mike Yang) (08/31/90)
There is no question that the X window system model is quite different
from that of SGI. To address some of your points:
1. Colormaps
The colormap mechanism is general enough to support colormaps of
various depths. Therefore, RGB values are specified as [0,65535]
rather than [0,255]. And this makes sense. Remember, the Xlib
routines that you use (e.g. XStoreColors) are based on the protocol,
which has remained consistent for all revisions of X11. It would have
been silly for the X designers to limit this and assume that no
hardware vendor would come up with a colormap visual with fewer than 8
planes.
The other advantage to this model is that if you then compile your
program and run it on a machine with a different size colormap (e.g. a
4 plane DEC system), it will run the same. Remember, X programs are
suppose to be portable and work generally the same way on different
hardware situations.
2. Local image storage and sending the result to the server
Because X is based on a client/server model, your image processing
client can build its own data but then needs to send it to the server
for display. This is different from GL, where your client application
can write directly to the screen hardware. X requires this
indirection because X clients can run on remote hosts.
As for your specific problem, images can be sent to the server in
quantities greater than one pixel. If you use XCreateImage to create
a local image data structure, XPutImage will send any region
(including the whole thing) to the server.
3. Window placement
The X model is that there is a window manager which governs the
handling of windows. Its policy varies from window manager to window
manager. Apparently, the one you're using is configured for "user
positioning," meaning that windows are interactively placed by the
user when they are mapped.
Clearly, people who are used to the GL model and who have had prior GL
experience will find X to be quite different and initially, difficult.
But this is true when learning anything new. Personally, I found the
GL model different and difficult because I was used to X.
There is going to be a learning curve for people migrating to X. The
best way to reduce this is to find people knowledgable about X and ask
them questions. Believe it or not, this set of people is much greater
than the X Consortium.
-----------------------------------------------------------------------
Mike Yang Silicon Graphics, Inc.
mikey@sgi.com 415/335-1786khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (09/01/90)
...misc folks
domain software written for X windows(something you can't say about
SGI's NeWS)
Unless I am mistaken, NeWS was created by Sun. SGI provides a fine
implementation, but one should not forget from whence it came.
It is quite possible to have X and NeWS at the same time. I am keying
this in from such an implementation.
NeWS may yet gain converts as folks bump up against X limitations.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043ghelms@sgi.com (Gretchen Helms) (09/01/90)
(Tim Moore) writes: >(Steve Lehar) writes: >Like the man said, see XSetWMNormalHints. > >> >> win = XCreateWindow(display, RootWindow(display, screen), >> xsh.x, xsh.y, xsh.width, xsh.height, >> bw, vTemplate.depth, InputOutput, visual, >> valuemask, &attrib); >> >>Note that there is no argument for x and y screen location! How do I >>tell this XWindow where to appear? > >It is true that you can't specify with certainty where your window >will end up on the screen. The rationale for this is that your window >manager might have a different idea about where the newly created >window should go. Hence, you give the window manager "hints". As an example, please consider the following code. This code will place the window correctly if you are either executing it under 4Sight, or if you execute it under UWM. My apologies for the not-so-hot commenting, I haven't gotten to the full comments on this one yet. ----------------------mangle here----------------------- /* 6/11/90 G. "Murdock" Helms, SGI Product Support * * First run: This file is a sample X program designed to * show how to start up a basic X window in a specified position. */ #include <X11/Xlib.h> /* Xlib include files */ #include <X11/Xutil.h> /* Must have these included */ #include <stdio.h> /* have to include this to know about NULL */ /* Display and screen are used as arguments to nearly every Xlib * routine, so it simplifies things to declare them global. */ Display *display; int screen; main() { Window win, rootwin; XSizeHints sizehints; char *window_name = "Placed Window"; char *icon_name = "bwin"; char *display_name = NULL; int x=100,y=100; unsigned int width=400, height=400; /* Connect to X server ... this is kind of a fancy test to make * sure the server is running, but it produces a nicer error code * than you normally get. */ if ( (display=XOpenDisplay(display_name)) == NULL ) { fprintf( stderr, "bwin: cannot connect to X server %s,", XDisplayName(display_name)); fprintf( stderr, "did you remember to set the DISPLAY?\n"); exit ( -1 ); } /* Get screen from display structure macro */ screen = DefaultScreen(display); /* Create opaque window ... note that BlackPixel and WhitePixel * are macros. */ rootwin = RootWindow(display, screen); win = XCreateSimpleWindow (display, rootwin, x, y, width, height, 5, BlackPixel(display, screen), WhitePixel(display, screen)); sizehints.flags=USPosition; /* so it can be either/or */ sizehints.x=x; /* this is part of XSizeHints */ sizehints.y=y; /* see manual on structure of */ /* Set properties for window manager (always before mapping!) */ XSetStandardProperties(display, win, window_name, icon_name, None, 0, 0, &sizehints); /* Display window */ XMapWindow(display, win); XFlush(display); while (1) {} /* loopity loop */ } /* end main */ -------------------------------mangle here--------------- -- G. "Murdock" Helms Is it so frightening Silicon Graphics to have me at your shoulder? Product Support Engineer Thunder and lightning ghelms@sgi.sgi.com couldn't be bolder.
joe@etac632 (Joe Fulson-Woytek) (09/01/90)
In article <SLEHAR.90Aug31102639@cochlea.bu.edu> slehar@cochlea.bu.edu (Steve Lehar) writes:
#
#Yes they do, but what about if I am WRITING the application? I can
#make my program receive the -geometry flag (or reasonable facsimile)
#but what do I DO with that information? When I open my XWindow I use
#the call
#
# win = XCreateWindow(display, RootWindow(display, screen),
# xsh.x, xsh.y, xsh.width, xsh.height,
# bw, vTemplate.depth, InputOutput, visual,
# valuemask, &attrib);
#
#Note that there is no argument for x and y screen location! How do I
#tell this XWindow where to appear?
The routine XSetStandardProperties can be called after the XCreateWindow
(we use XCreateSimpleWindow but it shouldn't matter). There is an XSizeHints
struct which includes the position and size. Be sure to set
the flags parameter to USPosition. The helloworld program in the
"Introduction to the X Window System" by Oliver Jones shows an example
of this which we used (except in the book the flags is set to PPosition
which won;t work on the Iris. If you email me I could send you a helloworld
type program which demonstrates this.
Joe FUlson-Woytekjim@baroque.Stanford.EDU (James Helman) (09/01/90)
slehar@bucasb.bu.edu writes: (My X image windows are prone to suddenly disappearing if they've been around for a while) My advice is to stick with SGI! This is *not* a problem inherent in X, rather the result of bugs in SGI's early implementations. The trouble is that if you want to do image processing you have to get your image data into that structure, and the only routine they provide sends the pixels over one by one, OVER THE NETWORK! so that even when you display from your own private terminal to your own private screen it goes... "Prepare to receive pixel", "sending pixel", "confirm receipt of pixel", "prepare for next pixel"... and so forth and of course it takes an eternity to send a whole image! There's no need to use single pixel transfers, but the basic problem of trying to cram lots of data down a narrow pipe is inherent in imaging on network window systems. There are various implementations that use shared memory for these transfers when possible. Sun has something along these lines called Direct Graphics Access. Perhaps, SGI will work to improve X's image transfer performance as well as supporting GL calls in X windows. moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) writes: on the SGI, X just plain doesn't work worth a darn under 3.2.x. Hopefully 3.3 is much better. It is *much better*. I've been running the IRIX 3.3 X server since the end of June, and it hasn't dumped core once. Some irritating drawing bugs remain, but hopefully these will be fixed soon. Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Voice: (415) 723-9127
mikey@eukanuba.wpd.sgi.com (Mike Yang) (09/02/90)
In article <KHB.90Aug31121450@chiba.Eng.Sun.COM>, khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes: |> It is quite possible to have X and NeWS at the same time. I am keying |> this in from such an implementation. |> |> NeWS may yet gain converts as folks bump up against X limitations. Or alternatively, a Display Postscript extension to X as DEC has done with their servers. The DPS extension has the advantage of doing both DPS calls and X calls to the same window. ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
slehar@cochlea.bu.edu (Steve Lehar) (09/04/90)
When I complain that X doesn't allow advance positioning of the window, joe@etac632 says... ----------------------------------------------------------------------- | There is an XSizeHints struct which includes the position and size. Be | sure to set the flags parameter to USPosition. The helloworld program | in the "Introduction to the X Window System" by Oliver Jones shows an | example of this which we used... ----------------------------------------------------------------------- I followed that same helloworld template, but somehow, when I modified it to do images, it ceased to go to where it was supposed to. I loaded up my XSizeHints as required... /**** set window position and size hints ****/ xsh.flags = (PPosition | PSize); xsh.x = 100; <------- please put window at position 100,100 xsh.y = 100; xsh.height = win_ysize; xsh.width = win_xsize; but it simply ignored this "hint". bernie@ecr.mu.oz.au (Bernie Kirby) tells me that the secret is ... "you have to set the "override_redirect" thingy to True somewhere." Well, this is likely to be the kind of thing that has to be done. Do you see my complaint? This kind of thing is typical of X. If it was better designed, the window position should either be defined in the window hints structure, or should be a parameter to XCreateWindows(). In fact, you can be intimately familiar with BOTH of these things and STILL not be able to position your window because you haven't read about the undocumented "override_redirect" thingy! X is just full of such hidden mysteries! I don't doubt that these things can be done somehow, but I'm afraid you need a PhD in XOlogy to just open a window and put an image in it! -- (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O) (O)((O))((( slehar@bucasb.bu.edu )))((O))(O) (O)((O))((( Steve Lehar Boston University Boston MA )))((O))(O) (O)((O))((( (617) 424-7035 (H) (617) 353-6425 (W) )))((O))(O) (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)
mikey@eukanuba.wpd.sgi.com (Mike Yang) (09/05/90)
In article <SLEHAR.90Sep4105933@cochlea.bu.edu>, slehar@cochlea.bu.edu (Steve Lehar) writes: |> |> When I complain that X doesn't allow advance positioning of the |> window, joe@etac632 says... |> |> ----------------------------------------------------------------------- |> | There is an XSizeHints struct which includes the position and size. Be |> | sure to set the flags parameter to USPosition. The helloworld program |> | in the "Introduction to the X Window System" by Oliver Jones shows an |> | example of this which we used... |> ----------------------------------------------------------------------- |> |> I followed that same helloworld template, but somehow, when I modified |> it to do images, it ceased to go to where it was supposed to. I |> loaded up my XSizeHints as required... |> |> /**** set window position and size hints ****/ |> xsh.flags = (PPosition | PSize); It might help if you set the USPosition flag (reread what you were instructed to do). In any case, these are "hints" and not guaranteed to work. For instance, suppose I want my window manager to always let me position a client window regardless of what the application developer wanted to place it. In X, it's possible to implement such a feature in a window manager. For this reason, X differentiates between user-specified positions (USPosition) and program-specified positions (PPosition). Window managers are expected (but not forced) to honor user-specified positions, but program-specified positions can be overriden. For instance, if the window manager tiles windows or if it's configured as in my example. |> but it simply ignored this "hint". bernie@ecr.mu.oz.au (Bernie Kirby) |> tells me that the secret is ... |> |> "you have to set the "override_redirect" thingy to True somewhere." This works, but is not the solution. Setting the override_redirect attribute for a window is well-documented, and says that the window manager should not get involved. When this happens, of course your window is placed where you wanted it. But then, you can't do things like iconify it or move it. |> Well, this is likely to be the kind of thing that has to be done. Do |> you see my complaint? This kind of thing is typical of X. If it was |> better designed, the window position should either be defined in the |> window hints structure, or should be a parameter to XCreateWindows(). |> In fact, you can be intimately familiar with BOTH of these things and |> STILL not be able to position your window because you haven't read |> about the undocumented "override_redirect" thingy! X is just full of |> such hidden mysteries! I don't doubt that these things can be done |> somehow, but I'm afraid you need a PhD in XOlogy to just open a window |> and put an image in it! You don't need a Ph.D. Sometimes, you just have to read the manual. ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
msc@ramoth.esd.sgi.com (Mark Callow) (09/05/90)
In article <JIM.90Aug31144126@baroque.Stanford.EDU>, jim@baroque.Stanford.EDU (James Helman) writes: |> |> There's no need to use single pixel transfers, but the basic problem |> of trying to cram lots of data down a narrow pipe is inherent in |> imaging on network window systems. There are various implementations |> that use shared memory for these transfers when possible. Sun has |> something along these lines called Direct Graphics Access. Perhaps, |> SGI will work to improve X's image transfer performance as well as |> supporting GL calls in X windows. |> DGA is a mechanism that allows graphics intensive applications to talk directly to the graphics hardware completely bypassing the window server. It is not as Jim suggests, a shared memory connection between client and server. SGI has always had "direct graphics access". We've simply never marketed it as a feature. To us it's a necessity. I showed Sun how to do DGA in NeWS. On Sun's, DGA only improves performance for XGL (no relation), and possibly SunPHIGS, applications. It does nothing for X applications. On the SGI only GL applications have direct access to the graphics hardware. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
jeremy@cs.ua.oz.au (Jeremy Webber) (09/05/90)
In article <SLEHAR.90Sep4105933@cochlea.bu.edu> slehar@cochlea.bu.edu (Steve Lehar) writes:
[lots of disparaging things about X]
It seems to me that you are using the raw X library when perhaps it would be
more appropriate to use the X Intrinsics library, and the Athena Widgets
toolkit. What you are doing looks like the equivalent of writing all your SGI
applications in raw Postscript, rather than using the GL.
To the point made in the original article, I would be surprised if Silicon
Graphics moved to X without porting the Graphics Library to run under a pure X
server. I certainly see no reason why this couldn't be done.
-jeremy
--
--
Jeremy Webber ACSnet: jeremy@chook.ua.oz
Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au
60 Hutt St, Adelaide 5001, Voicenet: +61 8 223 2430
Australia Papernet: +61 8 272 2774 (FAX)pkr@sgi.com (Phil Ronzone) (09/06/90)
In article <1990Sep4.175023.20768@relay.wpd.sgi.com> mikey@sgi.com writes: >|> "you have to set the "override_redirect" thingy to True somewhere." > >This works, but is not the solution. Setting the override_redirect >attribute for a window is well-documented, and says that the window >manager should not get involved. When this happens, of course your >window is placed where you wanted it. But then, you can't do things >like iconify it or move it. >... >You don't need a Ph.D. Sometimes, you just have to read the manual. No, the original complaint was valid. It IS poorly documented. It took me a while to find out about this, and "override_redirect" is a very poorly explained thiny at that. -- <----------------------------------------------------------------------------> Philip K. Ronzone S e c u r e U N I X pkr@sgi.com Silicon Graphics, Inc. MS 9U-500 work (415) 335-1511 2011 N. Shoreline Blvd., Mountain View, CA 94039 fax (415) 969-2314
jim@baroque.Stanford.EDU (James Helman) (09/06/90)
Obviously, I'm not very familiar with Sun's graphics. From what Mark says, I take it that Sun's DGA does not allow XGL and X drawing calls to be made in the same window. Basically then, it just allows XGL and X/NeWS windows to share the same screen without trouncing on each other. Once SGI's current window coexistence problems are fixed, will SGI's GL/X dichotomy be pretty much the same as Sun's XGL/X split? That is once a window is opened either as a local X window or as a "direct" graphics window, there is no way to get a handle for applying the other's drawing calls on that window? I've heard Vicom's new image processor supports something like this, allowing very high performance imaging operations when a local X window is accessed via another library interface. My other question: shared memory X transport? It seems like it would be a big win for portable X imaging applications like LLNL's View. Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Voice: (415) 723-9127
robert@texas.esd.sgi.com (Robert Skinner) (09/06/90)
In article <JIM.90Sep5130747@baroque.Stanford.EDU>, jim@baroque.Stanford.EDU (James Helman) writes: |> ... Vicom's new image processor ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just FYI, this must be the Pixar hardware. Pixar sold their hardware division to Vicom. I don't know what this implies about hardware/software support for X and/or "Direct Access". Robert Skinner robert@sgi.com They are your parent's worst nightmare -- because they ARE your parents. - Radio add about the Jefferson Airplane reunion concert, Berkeley, Sept '89
msc@ramoth.esd.sgi.com (Mark Callow) (09/06/90)
In article <JIM.90Sep5130747@baroque.Stanford.EDU>, jim@baroque.Stanford.EDU (James Helman) writes: |> Once SGI's current window coexistence problems are fixed, will SGI's |> GL/X dichotomy be pretty much the same as Sun's XGL/X split? That is |> once a window is opened either as a local X window or as a "direct" |> graphics window, there is no way to get a handle for applying the |> other's drawing calls on that window? After t-day (or should that be X-day) a program will be able to make windows using either X calls (referred to as an X client) or the existing GL calls (referred to as a GL client). GL clients will draw in the window using the GL just as they do today. GL clients can obtain the X window id of the window if desired. An X client may use new GL calls to initialize the GL, obtain a GL rendering context and bind that context to the X window of their choice. They then render into that window using the usual GL calls. I'm not sure if the X client will also be able to render using X calls. One of our server gods can answer more authoritatively than I. Even if it's possible, we don't recommend doing it. Trying to image into the same window using both X and the GL raises a bunch of nasty issues of which one of the nastiest is synchronizing the drawing. Has the GL finished drawing this polygon so I can have X draw this line? Who's on first so to speak. Ugh!! In case anybody misunderstands what I mean by the "same window" let me explain. You will be able to make a top level X window with several subwindows. You may image into one of more of the subwindows using the GL and into the remaining subwindows using X. What we do not recommend is trying to render into the same subwindow using both GL and X. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
gilles@cannes.Eng.Sun.COM (Patrick-Gilles Maillot) (09/06/90)
On the net yesterday: > >From what Mark says, I take it that Sun's DGA does not allow XGL and X >drawing calls to be made in the same window. Basically then, it just >allows XGL and X/NeWS windows to share the same screen without trouncing >on each other. > You should not rely on SGI to get information about the capabilities of XGL, Sun's DGA, or Sun in general... XGL and X calls CAN be made in the same window. Obviously, XGL calls are using DGA and therefore will be much faster in terms of rendering speed. It's time we start an Sun/XGL news group. -Patrick-Gilles Maillot
jim@baroque.Stanford.EDU (James Helman) (09/07/90)
jim@baroque.Stanford.EDU (James Helman) writes:
... Vicom's new image processor ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Just FYI, this must be the Pixar hardware.
Pixar sold their hardware division to Vicom.
Right idea, wrong acquisition. Within the past 18 months, Vicom
bought Gould's Imaging and Graphics Division as well as Pixar's
hardware division. Their new image processor originated at the former.
Jim Helman
Department of Applied Physics Durand 012
Stanford University FAX: (415) 725-3377
(jim@KAOS.stanford.edu) Voice: (415) 723-9127drb@eecg.toronto.edu (David R. Blythe) (09/07/90)
In article <1990Sep6.010419.1573@odin.corp.sgi.com> msc@sgi.com writes: > >Even if it's possible, we don't recommend doing it. Trying to image into >the same window using both X and the GL raises a bunch of nasty issues of >which one of the nastiest is synchronizing the drawing. Has the GL finished >drawing this polygon so I can have X draw this line? Who's on first so to >speak. Ugh!! > It would be really really really really nice if whatever X toolkit/UIMS/etc gets fobbed off on me (i.e. Motif,OpenLook) also works with GL graphics. That is to say, I want to learn *one* subroutine library for popups, pulldowns, radio knobs, other crap that can be used in both a GL window and an X window. This would seem like a good reason to have X requests and GL requests work together, rather than making a GL version of the same library. If a client is local can't it use the same direct paths to the hardware as GL (i.e. have X built on top of or in conjunction with GL (either through the X server, or bypassing it when possible) rather than a separate entity)? Remote requests would have to go through a serializer, so the remote guy may pay some performance penalty in extra overhead but it seems worth it to keep the local stuff fast and integrated. drb@clsc.utoronto.ca >-- >From the TARDIS of Mark Callow >msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc
kurt@cashew.asd.sgi.com (Kurt Akeley) (09/07/90)
In article <1990Sep6.175301.18898@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: |> In article <1990Sep6.010419.1573@odin.corp.sgi.com> msc@sgi.com writes: |> > |> >Even if it's possible, we don't recommend doing it. Trying to image into |> >the same window using both X and the GL raises a bunch of nasty issues of |> >which one of the nastiest is synchronizing the drawing. Has the GL finished |> >drawing this polygon so I can have X draw this line? Who's on first so to |> >speak. Ugh!! |> > |> |> It would be really really really really nice if whatever X toolkit/UIMS/etc |> gets fobbed off on me (i.e. Motif,OpenLook) also works with GL graphics. |> That is to say, I want to learn *one* subroutine library for popups, |> pulldowns, radio knobs, other crap that can be used in both a GL window and an |> X window. This would seem like a good reason to have X requests and GL |> requests work together, rather than making a GL version of the same library. You'll be able to use the same X-based toolkit with both X and GL applications. Remember, the popups, pulldowns, radio knobs, and other crap all are created as subwindows, not as part of the current window. What you won't be able to do is to blend (or logicop, or z-buffer, or texture map) a popup, pulldown, radio knob, or other crap INTO a GL scene. -- kurt
msc@ramoth.esd.sgi.com (Mark Callow) (09/08/90)
In article <1990Sep6.175301.18898@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: |> It would be really really really really nice if whatever X toolkit/UIMS/etc |> gets fobbed off on me (i.e. Motif,OpenLook) also works with GL graphics. |> That is to say, I want to learn *one* subroutine library for popups, |> pulldowns, radio knobs, other crap that can be used in both a GL window and an |> X window. This would seem like a good reason to have X requests and GL |> requests work together, rather than making a GL version of the same library. Apparently you didn't read the last paragraph of my message where I pointed out that you will be able to to mix GL and X subwindows within a single top-level window. This is all the support you need to use any of the X toolkits. |> If a client is local can't it use the same direct paths to the hardware as GL |> (i.e. have X built on top of or in conjunction with GL (either through the |> X server, or bypassing it when possible) rather than a separate |> entity)? Remote requests would have to go through a serializer, so the remote |> guy may pay some performance penalty in extra overhead but it seems worth it |> to keep the local stuff fast and integrated. It can be done but remember we are talking about a fast path to the graphics hardware which is a very different thing than the X server. Xlib has to be extensively rewritten, a fairly massive undertaking that is difficult to do without breaking fundamental things about X. IBM has done it. Unfortunately their system decides which version of Xlib to use (the standard one or the rewritten one) based on whether the first display the client opens is local or remote. If a client opens a local display then a remote display ... oops. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
drb@eecg.toronto.edu (David R. Blythe) (09/12/90)
In article <1990Sep7.190102.28444@odin.corp.sgi.com> msc@sgi.com writes: >0747@baroque.Stanford.EDU> <1990Sep6.010419.1573@odin.corp.sgi.com> <1990Sep6.175301.18898@jarvis.csri.toronto.edu> > >Apparently you didn't read the last paragraph of my message where I pointed >out that you will be able to to mix GL and X subwindows within a single >top-level window. This is all the support you need to use any of the X >toolkits. Okay I misunderstood, despite your great pains. Rather than ask for more details, I just stated the problem I wanted solved. > >It can be done but remember we are talking about a fast path to the >graphics hardware which is a very different thing than the X server. I think this is a little contentious, the X protocol design shouldn't preclude doing fast graphics or having a fast path to the graphics hardware. I hope the goal and end result of the X protocol isn't low bandwidth graphics but rather just a temporary implementation difficulty. I'll certainly agree trying to retrofit X into GL is a pain, but the fewer hitches there are to using the combined interface (from performance, ease of use, and generality points of view) the better off we will all be. -drb
msc@ramoth.esd.sgi.com (Mark Callow) (09/13/90)
In article <1990Sep11.234709.27405@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: |> In article <1990Sep7.190102.28444@odin.corp.sgi.com> msc@sgi.com writes: |> > |> >It can be done but remember we are talking about a fast path to the |> >graphics hardware which is a very different thing than the X server. |> |> I think this is a little contentious, the X protocol design shouldn't |> preclude doing fast graphics or having a fast path to the graphics hardware. It's simply fact. The X server provides a number of services that can't be replaced by a fast path to many graphics hardware designs, for example imaging into pixmaps. In a similar vein, saveunders are a major headache when you have clients rendering independently. |> I hope the goal and end result of the X protocol isn't low bandwidth graphics |> but rather just a temporary implementation difficulty. I'll certainly agree I know people who contend that in some cases L. Bob chose some of the more computationally intensive rendering algorithms known to the state of the art at the time. The protocol design is such that you have to use those algorithms or be non-compliant. See the paper "Xtool: Safe X for Sun's" by Jon Steinhart from Xhibition '90 for more details. I haven't looked at the algorithms myself so I'm not ready to argue this position. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."