ernest@tandem.com (Ernest Hua) (09/27/90)
We have many many Sparc Stations w/ GX cards that need fast X servers. Any hints or suggestions appreciated. I understand that the Purdue enhancements are only for X11R3 ... Is this true? Our graphical performance is extremely slow even though all of our workstations have graphical accelerators. We are currently using X11 R4 with all 14 patches from MIT. Ernest Hua Tandem Computers 408-285-5580 ernest@tandem.com
jody@shell.COM (Jody Winston) (09/27/90)
The GX is not uset in X11R4. The GX is used, to some extents, in
Openwindows 2.0. If you are interested in a custom GX server contact
me (I've done custom server work for other companies).
Jody Winston jody@shell.com
..!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody
Consultant to:
Shell Development Company, Bellaire Research Center
P.O. Box 481, Room 2103, Houston, TX 77001 (Voice: 713 663-2676)cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/27/90)
> We have many many Sparc Stations w/ GX cards that need fast X servers. Any > hints or suggestions appreciated. I understand that the Purdue enhancements > are only for X11R3 ... Is this true? Our graphical performance is extremely > slow even though all of our workstations have graphical accelerators. We are > currently using X11 R4 with all 14 patches from MIT. I don't believe that the MIT X11R4 server exploits the GX board. In any case X11R4 contained many performance improvements over R3 and so the Perdue enhancements became obsolete. If you have a Sun with GX it is probably worth your while to fork out some cash for OpenWindows. OpenWindows will use the GX board if present. I believe the price is about $400 but I'm not certain of that. Note however that the GX board only improves performance for operations like line drawing and area fill. There is no significant improvement for BITBLT operations. Chris Flatters
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/28/90)
> As a member of the GX team at Sun, I would be very interested to know > which BITBLT operations you feel are not being accelerated. There *is* > hardware in the GX specifically designed to improve the performance of > BITBLT type operations. I'm probably being a little loose in my use of the BITBLT designation. What I really mean is XLoadImage (with and without various logical operators set in the graphics context) since this is the bitwise display operation I use the most. At one time I was running with the GX board unintentionally disabled due to an installation error so I managed to get timings for image loads both with the GX board enabled and disabled under OpenWindows 1.0.1 and found no measurable difference. Of course, now I mention it, I can't find my notes. Chris Flatters
david@eng.sun.com ("The chain that can be yanked is not the eternal chain.") (09/28/90)
In article <9009271559.AA04425@zia.aoc.nrao.edu> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: >Note however that the GX board only improves performance for operations >like line drawing and area fill. There is no significant improvement for >BITBLT operations. This is not correct, the GX provides a very significant speedup for "BITBLT" operations. It has a 16 pixel wide internal bus and function unit, and plane mask hardware, so screen to screen operations are about 4-10x faster than on a dumb frame buffer. Memory to screen operations get a more modest but still worthwhile speedup. Not that this has a lot to do with X. -- David DiGiacomo, Sun Microsystems, Mt. View, CA david@eng.sun.com
naughton@wind.Eng.Sun.COM (Patrick Naughton) (09/28/90)
|> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: |> |> > We have many many Sparc Stations w/ GX cards that need fast X |> servers. Any |> > hints or suggestions appreciated. I understand that the Purdue |> enhancements |> > are only for X11R3 ... Is this true? Our graphical performance is |> extremely |> > slow even though all of our workstations have graphical |> accelerators. We are |> > currently using X11 R4 with all 14 patches from MIT. |> |> I don't believe that the MIT X11R4 server exploits the GX board. In |> any |> case X11R4 contained many performance improvements over R3 and so |> the |> Perdue enhancements became obsolete. If you have a Sun with GX it |> is |> probably worth your while to fork out some cash for OpenWindows. |> OpenWindows will use the GX board if present. I believe the price |> is |> about $400 but I'm not certain of that. |> |> Note however that the GX board only improves performance for |> operations |> like line drawing and area fill. There is no significant improvement |> for |> BITBLT operations. |> |> Chris Flatters -- MIT X11R4 treats the GX as if it were dumb memory like the CG3, and since the GX was designed to be accessed through the hardware registers and rarely used in dumb memory mode, X11R4 on the GX is actually slower than on the CG3. OpenWindows Version 2 takes advantage of the GX to speed up just about every graphics operation. Most operations are sped up 2-10X: (these are X11perf numbers... first line is obviously CG3) 8X (~487/61) 2000 trep @ 16.4088 msec ( 60.9/sec): 500x500 rectangle 3000 reps @ 2.0520 msec ( 487.0/sec): 500x500 rectangle 7.2X 7200 reps @ 0.7341 msec (1360.0/sec): 100x100 rectangle 72000 reps @ 0.1019 msec (9820.0/sec): 100x100 rectangle 2.4X 300000 reps @ 0.0216 msec (46300.0/sec): 10-pixel line segment 600000 reps @ 0.0090 msec (111000.0/sec): 10-pixel line segment 10.8X 3000 reps @ 2.0418 msec ( 490.0/sec): Fill 100x100 trapezoid 30000 reps @ 0.1883 msec (5310.0/sec): Fill 100x100 trapezoid 5.5X 10000 trep @ 2.5508 msec ( 392.0/sec): Scroll 100x100 pixels 20000 reps @ 0.4600 msec (2170.0/sec): Scroll 100x100 pixels 8X 200 reps @ 46.3777 msec ( 21.6/sec): Scroll 500x500 pixels 900 reps @ 5.8047 msec ( 172.0/sec): Scroll 500x500 pixels 4.8X 120 reps @ 54.4628 msec ( 18.4/sec): Copy 500x500 from window to window 800 reps @ 11.2341 msec ( 89.0/sec): Copy 500x500 from window to window OpenWindows Version 2 is available for $295 and includes tapes and unlimited right to use and a complete set of Sun documentation and O'Reilly Books #0,1,2,3, and 7. Additional sets of documentation are $195. Call your Sun sales office for more information. -Patrick ______________________________________________________________________ Patrick J. Naughton ARPA: naughton@sun.com Window Systems Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: (415) 336 - 1080
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/28/90)
>>Note however that the GX board only improves performance for operations >>like line drawing and area fill. There is no significant improvement for >>BITBLT operations > >Aiee! Not true! The GX accelerates blitting .... for a >more informal comparison, try running the "images" demo (found in the >"demos" program, under "The NeWS Toolkit" > "Imaging" > "Images"): >stretch out the frame and put an image in "bounce" mode. This blits a >color image all around the frame, and is much faster on a GX than on a >non-GX machine. Hmm. The NeWS image bounce is running entirely in the server. I was thinking more of operations that involve client-server data transfers. Is it possible that I am not seeing any improvement because I am limited by the bandwidth of the client server connection? The timings I have are for a fairly large image (512x512) and it is noticable that it appears in 3 or 4 chunks. What sort of bandwidth should I expect for a UNIX domain socket on a SPARCstation 1? Chris Flatters
janssen@parc.xerox.com (Bill Janssen) (09/28/90)
In article <1990Sep27.143140@wind.Eng.Sun.COM> naughton@wind.Eng.Sun.COM (Patrick Naughton) writes:
OpenWindows Version 2 takes advantage of the GX to speed up just about
every graphics operation. Most operations are sped up 2-10X:
But make sure that your application uses graphics operations before you
switch: Drawing non-fixed-width fonts (most of Andrew, for example), seems
about as fast on MIT X11R4 as on xnews 2.0. xterm, on the other hand, is
recognizably faster (5-6X?).
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304naughton@wind.Eng.Sun.COM (Patrick Naughton) (09/28/90)
|> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: |> I'm probably being a little loose in my use of the BITBLT designation. |> What I really mean is XLoadImage (with and without various logical |> operators set in the graphics context) since this is the bitwise display |> operation I use the most. At one time I was running with the GX board |> unintentionally disabled due to an installation error so I managed to |> get timings for image loads both with the GX board enabled and disabled |> under OpenWindows 1.0.1 and found no measurable difference. Of course, |> now I mention it, I can't find my notes. |> |> Chris Flatters -- XLoadImage performance has very little to do with which framebuffer you are using... Most of the time it takes to view an image using xloadimage is spent reading the image from disk, converting it to the XImage format from GIF/TIFF/et.al., and copying the data across the network connection via XPutImage. A more useful test of "BITBLT" would be to time XCopyArea requests from offscreen Pixmaps to screen windows and from screen-to-screen, (panning/scrolling). Coincidentally, you can test this using xloadimage: resize the window smaller than the image and when you see the little four-way-arrow cursor, press the left button and drag the image around. The difference between a GX and a CG3 is quite noticable... After re-reading your message I can imagine that you meant to say XPutImage() the Xlib request, and not xloadimage the (very nice) image viewing client by Jim Frost at Saber. The above comments still apply, with the clarification that XPutImage is a client side request which requires the image data to be serialized and written to the network connection and re-assembled in the server at the rate of the network connection... No graphics accellerator in the world can speed up the network. The MIT-SHM extension can help reduce the overhead by using shared memory and mmap() to speed up X{Get,Put}Image when the client and server are on the same machine. Hope this helps. -Patrick ______________________________________________________________________ Patrick J. Naughton ARPA: naughton@sun.com Window Systems Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: (415) 336 - 1080
mark@parc.xerox.com (Mark Weiser) (09/28/90)
We find the biggest win for blit operations from a client is to use the shared memory extension in X11R4. This is not in OpenWindows 2.0, so OW 2.0 is slower on our GX sparcstations that X11R4 from MIT. We don't use OW much. -mark -- Spoken: Mark Weiser ARPA: weiser@xerox.com Phone: +1-415-494-4406
jeremy@EIK.II.UIB.NO (09/28/90)
OpenWindows 2.0 can be as much as 100x faster for some window
operations. I've carried out some rough comparisons using xgc. Some
rough results are:
o OW 2.0 is about 10% slower than MIT X11R4 on a mono Sparcstation1 for most
operations (this is surprising - didn't sun do some of the work on
the generic X server? Their name is plastered all over the source).
o OW 2.0 is faster than MIT X11R4 on a GX sparc for all operations.
Using xgc, the following results were obtained (all times in seconds):
Copy Area Solid Lines Stippled Lines
gc function MIT OW2.0 speedup MIT OW2.0 speedup MIT OW2.0 speedup
copy 3.22 0.50 6.4* 0.17 0.045 3.78 4.9 0.045 108.9
set 10.48 0.48 21.8 0.33 0.045 7.33 5.4 0.045 120.0
or 11.34 0.63 18.0 0.52 0.065 8.00 5.2 0.065 80.0
xor 11.82 0.65 18.2 0.53 0.065 8.16 5.3 0.065 81.5
clear 9.68 0.47 20.6 0.34 0.045 7.56 5.3 0.045 117.8
and 11.39 0.66 17.2 0.49 0.065 7.54 5.1 0.065 78.5
* This exercises the bitblt routine in the server (I think!)
All of these operations on a GX sparc are faster than any mono sparc
can achieve.
So as you can see, if you're in the business of drawing stippled lines in
your applications, then it pays to get a GX card and run OpenWindows 2.0 :-).
OW2.0 does seem slower for other things though. There is markely more swapping
going on, and it seems to take about 20% longer to transmit properties
(atoms) to the server. It also takes a lunch break to bring the thing up.
-------------------------------------------------------------------------------
Jeremy Cook .----.
Parallel Processing Laboratory / / / / /
University of Bergen / / / / /
Thormoehlensgate 55 /----' .----. .----. .----. / / .----. /----.
N-5008 Bergen / _____/ / _____/ / / _____/ / /
Norway / (____/ / (____/ / / (____/ (____/
-------------------------------------------------------------------------------
email : jeremy@eik.ii.uib.no | "My other computer is a MasPar MP1208"
phone : +47 5 54 41 74 (direct) |
fax : +47 5 54 41 99 |
-------------------------------------------------------------------------------
Disclaimer: I do not work for Sun, I'm just a user of their products.naughton@wind.Eng.Sun.COM (Patrick Naughton) (09/29/90)
In article <545@roo.UUCP>, mark@parc.xerox.com (Mark Weiser) writes: |> |> We find the biggest win for blit operations from a client is to |> use the shared memory extension in X11R4. This is not in OpenWindows 2.0, |> so OW 2.0 is slower on our GX sparcstations that X11R4 from MIT. |> We don't use OW much. |> |> -mark |> |> -- |> Spoken: Mark Weiser ARPA: weiser@xerox.com Phone: +1-415-494-4406 -- You must be misinformed: % xdpyinfo -display unix:0 name of display: unix:0.0 version number: 11.0 vendor string: X11/NeWS - Sun Microsystems Inc. vendor release number: 2000 <<<<----------- Version 2 OpenWindows maximum request size: 16384 longwords (65536 bytes) motion buffer size: 100 bitmap unit, bit order, padding: 32, MSBFirst, 32 image byte order: MSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 keycode range: minimum 8, maximum 132 number of extensions: 2 SunWindowGrabber MIT-SHM <<<<<<------------------------------- default screen number: 0 number of screens: 2 ... The MIT-SHM extension is the same as the one in X11R4. -Patrick ______________________________________________________________________ Patrick J. Naughton ARPA: naughton@sun.com Window Systems Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: (415) 336 - 1080
mark@parc.xerox.com (Mark Weiser) (09/29/90)
I was wrong. The shared memory extension IS in the released OW 2.0. Apologies. -mark -- Spoken: Mark Weiser ARPA: weiser@xerox.com Phone: +1-415-494-4406
janssen@parc.xerox.com (Bill Janssen) (09/29/90)
In article <JANSSEN.90Sep27193151@holmes.parc.xerox.com> janssen@parc.xerox.com (Bill Janssen) writes:
Drawing non-fixed-width fonts (most of Andrew, for example), seems
about as fast on MIT X11R4 as on xnews 2.0. xterm, on the other hand, is
recognizably faster (5-6X?).
Just to clarify, xterm uses ImageText8 calls, and Andrew textview uses
PolyText8 calls. The way that the protocol is designed, ImageText8
seems to have much less overhead than PolyText8. I'd expect it to be
faster in a properly optimized server.
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304rapatel@pilot.njin.net ( Rakesh Patel) (09/30/90)
The following patches should help:
From root@sun1.ruf.uni-freiburg.de (Martin Walter) Tue Jan 16 09:07:53 1990
Path: njin!rutgers!usc!snorkelwacker!ira.uka.de!sun1.ruf.uni-freiburg.de!root
From: root@sun1.ruf.uni-freiburg.de (Martin Walter)
Newsgroups: comp.windows.x
Subject: R4 Xsun, GX support
Keywords: R4 Xsun GX cgsix
Message-ID: <1990Jan16.140753.6017@sun1.ruf.uni-freiburg.de>
Date: 16 Jan 90 14:07:53 GMT
Organization: Rechenzentrum der Universitaet Freiburg, Deutschland
Lines: 75
Unfortunately R4 does not support the GX. Until Sun will adapt
Xsun to there hardware (hopefully!) I use following little 'quick
and dirty' patch. It accelerates only simple bitblock moves within the
screen, but is very useful in xterm-scrolling and opaque-moves.
Martin.
#########################################################################
*** server/Imakefile.orig Sun Dec 17 01:09:30 1989
--- server/Imakefile Tue Jan 16 13:30:27 1990
***************
*** 241,245 ****
SUNOBJS = ddx/sun/sunInit.o $(FONTUTIL)
SUNLIBS = $(SUN) $(CFB) $(DIX) $(BSD) $(SNF) $(MFB) $(MI) $(EXTENSIONS)
! SUNSYSLIBS = $(SYSLIBS) $(SUNWINDOWSLIBS)
XsunDIRS = $(SUNDIRS)
--- 241,245 ----
SUNOBJS = ddx/sun/sunInit.o $(FONTUTIL)
SUNLIBS = $(SUN) $(CFB) $(DIX) $(BSD) $(SNF) $(MFB) $(MI) $(EXTENSIONS)
! SUNSYSLIBS = $(SYSLIBS) $(SUNWINDOWSLIBS) -lpixrect
XsunDIRS = $(SUNDIRS)
*** server/ddx/cfb/cfbbitblt.c.orig Fri Dec 8 02:35:42 1989
--- server/ddx/cfb/cfbbitblt.c Tue Jan 16 13:01:03 1990
***************
*** 217,220 ****
--- 217,255 ----
}
+ /*---------------------------------------------------------------------*/
+
+ if ((pSrc->type == DRAWABLE_WINDOW)
+ && (pDst->type == DRAWABLE_WINDOW)
+ && (alu == GXcopy)
+ )
+ {
+ #include <pixrect/pixrect_hs.h>
+
+ static Pixrect *screen = 0;
+ static planemaskSav = -999999;
+ if (!screen) screen = pr_open("/dev/fb");
+
+ if (planemask != planemaskSav) {
+ planemaskSav = planemask;
+ pr_putattributes(screen,&planemaskSav);
+ }
+
+ while(nbox--)
+ {
+ pr_rop( screen,
+ pbox->x1, pbox->y1,
+ pbox->x2 - pbox->x1, pbox->y2 - pbox->y1,
+ PIX_SRC, screen,
+ pptSrc->x, pptSrc->y);
+ pbox++;
+ pptSrc++;
+ }
+ /* Important: Wait for Completion! */
+ pr_get(screen, 0, 0);
+
+ } else
+
+ /*---------------------------------------------------------------------*/
+
/* special case copy */
if (alu == GXcopy && (planemask & PMSK) == PMSK)
#########################################################################
--
_____________________________________________________________________________
Internet: mawa@sun1.ruf.uni-freiburg.de (132.230.1.1) | Rechenzentrum Uni
X.400: G=martin;S=walter;OU=ruf;P=uni-freiburg;A=dbp;C=de | Freiburg, Germanycheeks@edsr.eds.com (Mark Costlow) (10/01/90)
The thing that burns me is that Sun refuses to release enough specs on the board for somebody that was so inclined to add support for it to the MIT release. Like a few others said, some people at my site use OW 2.0 because it's so much faster in certain areas, but most would prefer the freedom to use the MIT release, since there's typically a 6-month lag between the latest MIT release and when the vendor-supplied servers have merged the latest release (I'm only speaking from experience with Sun and HP here, but I suspect others are the same). We were pretty annoyed when we shelled out the bux for all those cg6 boards and then found out we couldn't use them the way we want (the way we SHOULD be able to). I find it hard to believe that Sun is worried about clones - they GAVE away SPARC, NFS, RPC, etc. I'm not asking for ROM masks, I just want programming specs . . . a library would be nice, but just telling me what regs are what and how to use them would be cool. I thought I was going to get my wish when I saw the note on the Aviator tape about giving away the source - until I saw the footnote that said they wouldn't make the source available until they REMOVED the GX register manipulation code. Ugh! Oh well ... you can be sure our next gaggle of Sparcs will come with CG3s ... or maybe they won't be Sparcs at all. We've been known to get inaccurate manure from the marketroids. If anyone can prove me wrong with different manure, or has reverse-engineered the board any, I'd love to hear it! Mark -- cheeks@edsr.eds.com or ...uunet!edsr!cheeks Disclaimer: I speak for myself, nobody else.
janssen@parc.xerox.com (Bill Janssen) (10/01/90)
In article <Sep.29.23.20.12.1990.3448@pilot.njin.net> rapatel@pilot.njin.net ( Rakesh Patel) writes:
Unfortunately R4 does not support the GX. Until Sun will adapt
Xsun to there hardware (hopefully!) I use following little 'quick
and dirty' patch. It accelerates only simple bitblock moves within the
Dirty is the word. Putting pixrect calls in the cfb code? Does this
wreak havoc on other kinds of machines or displays? And what happens
when the thing you're drawing on is not /dev/fb? Though I'm sure your
intentions are pure, I wish people wouldn't post this kind of garbage.
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304gjc@mitech.com (10/01/90)
In article <JANSSEN.90Sep30200715@holmes.parc.xerox.com>, janssen@parc.xerox.com (Bill Janssen) writes: > In article <Sep.29.23.20.12.1990.3448@pilot.njin.net> rapatel@pilot.njin.net ( Rakesh Patel) writes: > > Unfortunately R4 does not support the GX. Until Sun will adapt > Xsun to there hardware (hopefully!) I use following little 'quick > and dirty' patch. It accelerates only simple bitblock moves within the > > Dirty is the word. Putting pixrect calls in the cfb code? Does this > wreak havoc on other kinds of machines or displays? And what happens > when the thing you're drawing on is not /dev/fb? Though I'm sure your > intentions are pure, I wish people wouldn't post this kind of garbage. > Given a quick and dirty hack posted only for a subset of SUN machines why would "other kinds of machines and displays" be an issue? (Other than as a setup for calling something garbage later in the message). -gjc
mouse@LARRY.MCRCIM.MCGILL.EDU (10/02/90)
>> Unfortunately R4 does not support the GX. Until Sun will adapt Xsun >> to there hardware (hopefully!) I use following little 'quick and >> dirty' patch. Sun has already done so; just run their "Open"Windows server. (This is one of the problems I have with Sun: they don't document their hardware. Grrr.) > Dirty is the word. Putting pixrect calls in the cfb code? Does this > wreak havoc on other kinds of machines or displays? Presumably it is correctly protected with preprocessor conditionals. I don't have the patch online at the moment, so I can't check whether it was or not, but if it wasn't, at least complain about the proper thing! > And what happens when the thing you're drawing on is not /dev/fb? This is a more serious objection. To do it properly a hook should be put in to the ddx/sun code to pr_open() the correct device before blitting with pr_rop(). > Though I'm sure your intentions are pure, I wish people wouldn't post > this kind of garbage. It's not garbage. It's a useful, seriously nonportable[$], and slightly dangerous[%] patch. [%] Only slightly dangerous: what proportion of the Suns running X do you suppose have more than one framebuffer available? [$] Many users are interested in performace and are willing to do almost anything to get it, including putting machine-dependent code into cfb. As long as it degrades properly when on other machines, I have no problems with this. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rapatel@khnphwzhn.njin.net ( Rakesh Patel) (10/02/90)
I didn't write the code, but we use it, and it does result in very nice performance for color Suns that have a GX processor on them. This patch was used well before OpenWindows 2.0 even became available, so while it is a hack, it made it bearable for those who wanted a reasonable speed X11 server on their color Suns. No, it does not affect non-Suns, since the code is only used for suns, and we have not seen any problems using it. Rakesh Patel.
janssen@parc.xerox.com (Bill Janssen) (10/03/90)
In article <5454@mitech.com> gjc@mitech.com writes:
Given a quick and dirty hack posted only for a subset of SUN machines why
would "other kinds of machines and displays" be an issue?
The garbage posted affects a part of the source tree that is included
in the make for several kinds of machines. It is not protected by
#ifdefs. It contains several assumptions about environments that are
not globally valid. If a "naive" user were to apply it in our
environment here, it would break about a third of our workstations,
all of them Sun-4 SunOS 4 machines.
If the garbage made some rudimentary checks about its run-time
environment, and affect only files in the ddx/sun directory, I'd have
said nothing about it. Even so, the fact that *I* wish people
wouldn't post this kind of garbage doesn't mean that *you* shouldn't
enjoy it; no accounting for tastes.
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304rapatel@khnphwzhn.njin.net ( Rakesh Patel) (10/04/90)
> Given a quick and dirty hack posted only for a subset of SUN machines why > would "other kinds of machines and displays" be an issue? > >The garbage posted affects a part of the source tree that is included >in the make for several kinds of machines. It is not protected by >#ifdefs. It contains several assumptions about environments that are >not globally valid. If a "naive" user were to apply it in our >environment here, it would break about a third of our workstations, >all of them Sun-4 SunOS 4 machines. > >If the garbage made some rudimentary checks about its run-time >environment, and affect only files in the ddx/sun directory, I'd have >said nothing about it. Even so, the fact that *I* wish people >wouldn't post this kind of garbage doesn't mean that *you* shouldn't >enjoy it; no accounting for tastes. > >Bill I have to agree with Bill about the part where it contains no #ifdef's. I hadn't realized that it didn't contain them (it has been quite a while since I add that patch). When I put the patch into our distribution, I had added in the appropriate #ifdefs. Anyone using that code should definitely add the #ifdefs. I use: #if defined(sun) && defined(SUN_WINDOWS) ... #endif /* sun */ We currently don't have any machines configured with multiple frame buffers, so we have never had any problems with the code, however, I do agree with Bill that the ought to be done properly. Someone who has the patch does have such a situation and is likely to look into putting in the appropriate run-time conditionals. Rakesh Patel.