Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!exodus!europa.Eng.Sun.COM!jdn
From: jdn@europa.Eng.Sun.COM (Jeff Nisewanger)
Newsgroups: comp.windows.x
Subject: Re: OW as a PostScript X server...
Message-ID: <2787@exodus.Eng.Sun.COM>
Date: 14 Nov 90 21:36:34 GMT
References: <9011131842.AA08663@islanders.> <1990Nov13.231333.23226@crl.dec.com>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 87

In article <1990Nov13.231333.23226@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes:
>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


My understanding is that the PostScript code sent through the X/DPS
extension executes asynchronously from the X protocol requests sent over
the same connection. If they need to be executed in a reliable order then
you must explicitly synchronize the PostScript side much the same way
that you would if you had a separate NeWS connection.

This is from an Adobe document on the DPS X extension:
[Display PostScript system: X Window System Programmer's Supplement
 to the Client Library Reference Manual, Adobe, Jan. 23, 1990]

	"PostScript language programs run asynchronously with respect to other
	X requests. A PostScript language rendering request is not guaranteed
	to be complete before a subsequent X request is executed, unless
	synchronized."

It then refers off to another section which suggests 2-3 different ways
for the X client to effectively wait until the PostScript execution is
finished before it sends the X protocol requests that needed to be
synchronized with.

Under "4.9 Synchronization" the documentation states:

	"As discussed in Section 3.3.2, X rendering primitives and PostScript
	language execution may, in most cases, be intermixed freely. However,
	in some situations PostScript language execution needs to be
	synchronized with X.

	See the Client Library Reference Manual for a discussion of the general
	requirements for synchronization. To summarize, you can synchronize
	either by calling wraps that return results or by calling
	DPSWaitContext(). Enforced synchronization is expensize and should be
	used only when absolutely necessary."

This means you get a network round-trip if you really need to synchronize
the rendering between X and Display PostScript.



--
Jeff Nisewanger                         ARPA: jdn@Eng.Sun.COM
Window Systems Group                    UUCP: ...!sun!jdn
Sun Microsystems, Inc.                  415/336-5743