brian@radio.astro.utoronto.ca (Brian Glendenning) (10/18/88)
I will shortly be porting an application to an Iris 4D Turbo machine, and I am wondering which windowing system I should use. X or NeWS is attractive for portability reasons, but I don't know if they are as capable or as well done as 4Sight. My application deals largely with 24 bit raster images, plus overlay planes, colormap manipulation etc. Any suggestions as to utility, performance, implementation quality etc will be much appreciated. -- Brian Glendenning - Radio astronomy, University of Toronto brian@radio.astro.utoronto.ca uunet!utai!radio!brian glendenn@utorphys.bitnet
jim@THRUSH.STANFORD.EDU (Jim Helman) (10/21/88)
We have a 4D/70GT, a wonderful machine that is damn fast for lots of things. Sadly, X is not one of them. The X support is EXTREMELY SLOW for doing things like scrolling a window. It takes several seconds to scroll an 80 column, full screen height window. I'm hooked on gnuemacs with mouse and was very disappointed when I realized the speed of 4Sight's X11 support makes the machine unusable for this and many other X applications. It might get better in a release (it improved somewhat in the last release) or it may be a fundamental problem with doing bitblt style operations on the GT hardware. (Any comments from SGI on this?) In any case, it's forced me to do all my editing using X11 on a nearby VaxStation GPX. I only use the SGI screen for actually running my graphics programs. This is safer anyway, since while debugging a graphics program, a bad graphics library call can cause the window manager to die and take the whole console session with it. I don't know if 4Sight's NeWS has better pixel performance, but normally I would expect X to be better than NeWS for raster image operations, since X is built around a raster imaging model. Jim Helman Department of Applied Physics Stanford University
phil@BRL.MIL (Phil Dykstra) (10/21/88)
SGI seems to be redoing the X11 support for a future 4Sight release. We had a working X11 system (even if not very fast) under our first 4Sight release, and then a ..(no comment because it was a beta test).. X11 system. Now I hear that X will no longer be supplied with 4Sight until some future date. Perhaps SGI felt it was better not to include it, rather than have people (incorrectly) judge the performance of the machine based on the X support. I could understand this decision if true, but its only my conjecture as to why it went away. Personally I preferred having X support, whether fast or slow, to not having it at all. Since folks like Ardent and Stellar are basing their products on "high performance" X platforms, I trust that SGI will make a reasonable effort to provide a good X interface in the future. > In any case, it's forced me to do all my editing using X11 on a > nearby VaxStation GPX. Gee, we do all of our editing on Sun 3/50s :-). - Phil
miq@chromavac.SGI.COM (Miq Millman) (10/22/88)
In article <8810202336.AA03068@ucbvax.Berkeley.EDU>, jim@THRUSH.STANFORD.EDU (Jim Helman) writes: > > > I don't know if 4Sight's NeWS has better pixel performance, but > normally I would expect X to be better than NeWS for raster image > operations, since X is built around a raster imaging model. The reason that X is so much slower on our machines is because of the way it handles doing things like rubberbanding and highlighting. X uses XOR to change colors on the screen which is just fine for a monochrome no grey scale monitor, but it really sucks with color. On the SGI workstations, overlay planes are used for doing the same things that X tries to do with XOR. The graphics hardware is incredibly fast, so performace is not hurt. On the 4D series, pixel performance is about 8 million pixels per second. Incidently, a new version of X for our machines is being worked on and it should be released soon. > > Jim Helman > Department of Applied Physics > Stanford University -- "The Queen promised she would ream us with 20 inch cattle prods, and I'm STILL waiting!" -Rene' Henderson (aka Toshiro Baloney) _Forbidden Zone_ Miq Millman -- miq@sgi.com or {sun,decwrl,pyramid,ucbvax}!sgi!miq 415 336 1041 work
marcel@mlogic.UUCP (Marcel Samek) (10/24/88)
In article <20894@sgi.SGI.COM> miq@chromavac.SGI.COM (Miq Millman) writes: >graphics hardware is incredibly fast, so performace is not hurt. On the 4D >series, pixel performance is about 8 million pixels per second. > In the context of the discussion, which was about pixel based operations, this statement is utter nonsense. The architecture of the 4D series does not provide direct acess into the frame buffer and thus any pixel data generated by an application program must be passed down the geometry pipeline. While the 3D geometry engines may be able to get pixel performance of 8 million pixels per second when painting 3d data, application programs can achieve pixel performances of significantly less than 100,000 pixels per second (roughly 2 orders of magnitude less) when painting pixel data. If you wish to read pixels from the frame buffer, the performance is significantly slower than if you wish to write pixels. It is disappointing to see Silicon Graphics employees post such deceptive garbage to the net. Marcel -- Marcel A. Samek | Media Logic Incorporated | 2501 Colorado Blvd. Suite 350 ARPA: mlogic!marcel@unisys.sm.com | Santa Monica, CA 90404 UUCP: ...sdcrdcf!mlogic!marcel | (213) 453-7744
mtoy@xman.SGI.COM (Michael Toy -- The S.G.I. XMAN) (10/24/88)
In article <128@mlogic.UUCP>, marcel@mlogic.UUCP (Marcel Samek) writes: > In article <20894@sgi.SGI.COM> miq@chromavac.SGI.COM (Miq Millman) writes: > > >graphics hardware is incredibly fast, so performace is not hurt. On the 4D > >series, pixel performance is about 8 million pixels per second. > > In the context of the discussion, which was about pixel based operations, > this statement is utter nonsense. ... > > ... application programs can achieve pixel performances of > significantly less than 100,000 pixels per second (roughly 2 orders of > magnitude less) when painting pixel data. > > If you wish to read pixels from the frame buffer, the performance is > significantly slower than if you wish to write pixels. > > It is disappointing to see Silicon Graphics employees post such deceptive > garbage to the net. I believe the published speed for copying pixels to the screen from user memory on the GTX series machines IS 8 million pixels per second. So the only deception in the first posting is the phrase "on the 4D series". It should have been "on the multi-processor 4D series". -- From the mixed up files of Mr. Michael C. Toy Internet: mtoy@SGI.COM UUCP: {ames,ucbvax,decwrl,sun,parcvax}!mtoy
miq@chromavac.SGI.COM (Miq Millman) (10/25/88)
ooops, I meant to say on the Multi-processor as Michael Toy pointed out.
There was no malice or decieving intended in my message, only trying to
answer a question. If you really believe that this news group was set up
to frustrate and confuse users by SGI employees posting bogus info, then
perhaps you should Email me and we can discuss this further off the net.
--
"You know Squeezit, we chickens are hear to help in any way we can."
"But what can chicken do?"
"Precisely."
Squeezit and his chicken buddies in _Forbidden Zone_
Miq Millman -- miq@sgi.com or {sun,decwrl,pyramid,ucbvax}!sgi!miq
415 960 1980 x1041 work