Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!gatech!purdue!haven!decuac!bacchus.pa.dec.com!news.crl.dec.com!jg
From: jg@crl.dec.com (Jim Gettys)
Newsgroups: comp.windows.x
Subject: Re: OW as a PostScript X server...
Message-ID: <1990Nov13.231333.23226@crl.dec.com>
Date: 13 Nov 90 23:13:33 GMT
References: <9011131842.AA08663@islanders.>
Sender: news@crl.dec.com (USENET News System)
Reply-To: jg@crl.dec.com (Jim Gettys)
Organization: DEC Cambridge Research Lab
Lines: 42

In article <9011131842.AA08663@islanders.>, fgreco@fis1138.GOVt.shearson.COM (Frank Greco) writes:
> > 
> > The technical problem with the X11/NeWS merged server is the following:
> > 
> > If you want to mix X and PostScript based imaging models (and I know people
> > who do, for very good reasons; each imaging model has much to offer the
> > application programmer), you have to synchronize the two connections.  This is 
> > more than a minor pain to an application programmer in this cicumstances
> > (and can be a non-trival performance problem; it basically involves putting
> > XSync calls and equivalent everywhere you care about order, which requires
> > a server round trip); and comes naturally if you are talking to a server 
> > over a single connection.
> 
> 	I don't get it.  Why is this a "technical problem" with the X/NeWS
> 	merged server?  It is a concern wherever you want to mix imaging models.
> 
> 	I guess DEC wouldn't have the same problem mixing Display PostScript
> 	and Xlib...;->
> > 


If both PostScript and X rendering travel over the same communications path,
you get implicit ordering of requests (i.e. XDrawLine followed by
a PostScript text rendering call, for example, get rendered in the order
specified by your program, since they travel to the server in order
(guaranteed by the semantics of a connection).

The way the X11/NeWS merge server is done, PostScript and X travel over
two independent communications paths, and therefore you have to synchronize
them to get them to come out in the order you want since there are no
guarantees they would be rendered in the same order your program specified
them.

This is the the problem.  I don't much care if you do PostScript as an extension
to X, or the other way around, but you can't duck this problem anyway I
can see using two different server connections, short of lots of Sync calls
in your program, which seems more than a bit gross to me.

This has nothing to do with the imaging models whatsoever; it would be
equally true for PEX, or any other imaging model; it is solely a property
of the communications path.
				- Jim