Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!decuac!shlump.nac.dec.com!news.crl.dec.com!zorch.crl.dec.com!jg From: jg@zorch.crl.dec.com (Jim Gettys) Newsgroups: comp.windows.x Subject: Re: OW as a PostScript X server... Message-ID: <1990Nov15.021857.21755@crl.dec.com> Date: 15 Nov 90 02:18:57 GMT References: <9011131842.AA08663@islanders.> <1990Nov13.231333.23226@crl.dec.com> <2787@exodus.Eng.Sun.COM> Sender: news@crl.dec.com (USENET News System) Organization: DEC Cambridge Research Lab Lines: 111 In article <2787@exodus.Eng.Sun.COM> jdn@europa.Eng.Sun.COM (Jeff Nisewanger) writes: >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. I did say, some postings ago, I'd never programmed it :-). Shows anyone can get into hot water in areas one doesn't know intimately first hand. Clearly, if you start a PostScript code running with loops, you had better be able to synchronize. But the case I'm interested in is slightly different. The question is precisely what the "As discussed" paragraph above means, under what circumstances. It seems to imply that under most circumstances the right thing should happen, but not under others. Precisely what those circumstances are is the question at hand, and if the right guarantees are made. Maybe a DPS expert can clarify what it actually means. If DPS violates my rules above (which is really the principle of "don't surprise the poor programmer") such that simple immediate rendering commands can't be interspersed with X rendering commands and execute in the order the naive programmer expects, then I'm not happy with DPS as it currently stands, in which case, if true, as Shakespeare said: "A Pox on Both Your Houses." I do stand by my statements that a single connection is the correct approach, in order not to give programmers unneeded problems. - Jim Gettys -- Digital Equipment Corporation Cambridge Research Laboratory