SGI's migration to X

Mark Callow msc at ramoth.esd.sgi.com
Thu Sep 13 04:15:44 AEST 1990


In article <1990Sep11.234709.27405 at jarvis.csri.toronto.edu>,
drb at eecg.toronto.edu (David R. Blythe) writes:
|> In article <1990Sep7.190102.28444 at odin.corp.sgi.com> msc at 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 at 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."



More information about the Comp.sys.sgi mailing list