Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!apple!bloom-beacon!AARDVARK.UMD.EDU!jonnyg
From: jonnyg@AARDVARK.UMD.EDU (Jon Greenblatt)
Newsgroups: comp.windows.x
Subject: Re: New X Stations from Tektronix
Message-ID: <8907271729.AA01771@aardvark.UMD.EDU>
Date: 27 Jul 89 17:29:02 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 61


	I've been getting some interesting responses about my comment on
the 6152 systems. I would like to make a few points clear though.

	1: The 6152 is a fast X11 server. It is not an exceptional UNIX system
	   in terms of performance but it fairs pretty well

	2: As far as I know it is only available to academic institutions.
	   I'm not sure if a non acedemic institution can buy one.
	   Academic discount is not an issue if the only people who can
	   buy one are Academic institutions.

	3: An X server on a much faster system will probably perform better
	   but you also pay for speed.

	4: The 8514 driver is fast and reasonably well debuged. I have not
	   commented on AIX or other 4.3 drivers. I think IBM is getting on
	   the ball with color X, in time I would not be surprized if more
	   IBM X emulations were comparable.

(LONG: dealing with X Ports in general)


	I hope I am not giving away any trade secrets here but I do know
why the 8514 driver is so much faster than most other color drivers.
When I first got X10 for my RT, the only color monitor we had at the time
(IBMAPA8C) which only supported monochrome. Over time I hacked the mono
server in vary small ways to produce a reasonably fast partial color emulation.
The CFB code has been flamed for being incredably slow, I don't know if
that has changed yet or not? One thing I did notice looking through the
IBM distribution is that the color stuff uses mostly the MFB libraries
and almost nothing from the CFB libraries. Being that my first color
hack was to a mono server, I deduced IBM could have done it the same way.
The source to this server is not available but the supporting source and
symbol tables to the .o files were enough to figure out this was true.

	Has anyone else done work using the MFB code to produce color
servers?  It seems with most modern color hardware it should not be too
hard.  As long as you can set the READ/WRITE planes on the display and do
one bit per pixel access you can use MFB code to write to color displays.  I
would realy like to see every one have fast color displays, I'm not proud.
I have not looked at the CFB code closely but it seems to me that it is
written for the lowest common denominator of color display.  It seems using
any real features on a color display would make the CFB code obsolete(?).
If your hardware is one pixel per BYTE/WORD only I guess the CFB code is
all you can use, it would prabably be faste those conditions anyway.

	I wrote a pseudo subset of X10 for the IBM PC and turned it into
a non windowing graphics library. The code supported pixmaps and other
hard to do things. The displays supported included EGA COLOR, EGA MONO, VGA,
and MCGA and most graphics modes supported by each display. My driver code
was basicaly split in half. One half of the code delt with one bit per pixel
modes and the other half delt with one byte per pixel modes. There was
very little difference between mono and color modes. Maybe instead of MFB
being mono and CFB being color, MFB should be for bit mapped displays and
CFB should be byte mapped diplays.

	I don't claim to be server guru, what I said may acualy be documented
somewhere. I thought my observations would be of interest however.

					JonnyG.