janssen@parc.xerox.com (Bill Janssen) (11/10/90)
And, no X extensions are involved; you're guaranteed to get PS rendering with OW. That's right; you get it by involving a different world. You first create an X window, then open a second socket to the NeWS side of the server, then pass the window-id of the X window across to the NeWS world, then do PostScript'ish things to the NeWS world, while doing X'y things to the X world. Strikes me it would be "a good thing" to have a pseudo-Display PostScript extension to the OW server, so that a programmer could manipulate xnews just as they manipulate the DEC or IBM servers extended with real Display PostScript. The way it is now, you have no hope of running your (two-world) program on anything but xnews. Perhaps a "standard" extension for doing PostScript imaging is something the Consortium will address. Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (11/12/90)
> > And, no X extensions are involved; you're guaranteed to get PS > rendering with OW. > > That's right; you get it by involving a different world. You first > create an X window, then open a second socket to the NeWS side of the > server, then pass the window-id of the X window across to the NeWS > world, then do PostScript'ish things to the NeWS world, while doing > X'y things to the X world. > > Strikes me it would be "a good thing" to have a pseudo-Display > PostScript extension to the OW server, so that a programmer could > manipulate xnews just as they manipulate the DEC or IBM servers > extended with real Display PostScript. The way it is now, you have no > hope of running your (two-world) program on anything but xnews. What's wrong with that? Considering the current (and future) market that Sun and SPARC clones enjoy, that's not bad at all. If you design your software decently enuf (talk about your basic Pandora's box statement...;-)... you should be able to localize dependencies in imaging for different targets. The engineers at Frame did this. Ventura is doing the same with their product (GEM, MS Windows, PM, Mac and soon OpenLook versions). Should Borland stop marketing their Turbo line and TSR goodies because they "only run on PC's"? Was it a bad idea for Lotus to initially write 123 in 80X86 assembly? Is Bill Gates losing sleep due to Windows 3.0 "only" available on Intel-based machines? Not by any stretch of the imagination are these products elegant...successful?... > > Perhaps a "standard" extension for doing PostScript imaging is > something the Consortium will address. Not to be redundant, but: And, no X extensions are involved; you're guaranteed to get PS rendering with OW. Frank G. And what are the ...gulp...legal (and financial) ramifications with Adobe in this matter?
jg@crl.dec.com (Jim Gettys) (11/13/90)
In article <9011121513.AA06367@islanders.>, fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: > > > > And, no X extensions are involved; you're guaranteed to get PS > > rendering with OW. > > > > That's right; you get it by involving a different world. You first > > create an X window, then open a second socket to the NeWS side of the > > server, then pass the window-id of the X window across to the NeWS > > world, then do PostScript'ish things to the NeWS world, while doing > > X'y things to the X world. > > > > Strikes me it would be "a good thing" to have a pseudo-Display > > PostScript extension to the OW server, so that a programmer could > > manipulate xnews just as they manipulate the DEC or IBM servers > > extended with real Display PostScript. The way it is now, you have no > > hope of running your (two-world) program on anything but xnews. > > What's wrong with that? Considering the current (and > future) market that Sun and SPARC clones enjoy, > that's not bad at all. If you design your software decently > enuf (talk about your basic Pandora's box statement...;-)... > you should be able to localize dependencies in imaging for > different targets. The engineers at Frame did this. > Ventura is doing the same with their product (GEM, MS Windows, > PM, Mac and soon OpenLook versions). > 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 personally agree that it would be very nice to have a common X PostScript extension, that would work no matter what the implementation of X, so that applications programmers could count on it. And as to the rest of your message, isn't Shearson the brokerage house that has taken a big interest in Sun Microsystems? Or is it one of the other ones? - Jim
korp@atlantis.ees.anl.gov (Peter Korp) (11/13/90)
In article <1990Nov12.221429.23721@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes: >In article <9011121513.AA06367@islanders.>, fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: >> > >> > And, no X extensions are involved; you're guaranteed to get PS >> > rendering with OW. >> > [various ramblings deleted] >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. > This is only true to a certain extent. If you are only going to do imaging then no round trip is required. If you wish to use the NeWS input facilities as WELL AS the X input facilities then the problem you describe becomes an issue. >I personally agree that it would be very nice to have a common X PostScript >extension, that would work no matter what the implementation of X, so that >applications programmers could count on it. > Yes it would, note that nothing prevents the Adobe X-DisplayPostScript extension from working in OpenWindows, the question is why? It would be fairly easy to write a translator that understands the X-DP extensions and maps them to NeWS calls, after all part of X10 was emulated in NeWS 1.1. Performance would be the only issue. >And as to the rest of your message, isn't Shearson the brokerage house that >has taken a big interest in Sun Microsystems? Or is it one of the other >ones? > - Jim Kind of a cheap shot, no?? I happen to believe that the merging of X and NeWS was done in a much cleaner fashion than the DP extension to X, but that is just my opinion. Besides at least with OW I can tune the NeWS side of things to my hearts content, when will Adobe freely license DP? Peter ------------------------------------------------------------------------------ Argonne National Laboratory Advanced Computer Applications Center
jg@zorch.crl.dec.com (Jim Gettys) (11/13/90)
In article <1990Nov13.004034.5670@mcs.anl.gov> korp@atlantis.ees.anl.gov (Peter Korp) writes: >In article <1990Nov12.221429.23721@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes: >>In article <9011121513.AA06367@islanders.>, fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) writes: >>> > >>> > And, no X extensions are involved; you're guaranteed to get PS >>> > rendering with OW. >>> > > >[various ramblings deleted] > >>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. >> > >This is only true to a certain extent. If you are only going to do imaging >then no round trip is required. If you wish to use the NeWS input facilities >as WELL AS the X input facilities then the problem you describe becomes an >issue. Given that you are talking to a server over two separate connections, each with independent buffering in X, NeWS libraries, socket buffers and server buffers on both the client and the server, there is no way to guarantee sequentiality of output I can see without forcing a round trip on each connection. If I'm wrong, I'd be happy to understand how you avoid this. A flush just sends the data; it doesn't guarantee the server has processed it; I believe a sync in some form is required to get sequential output for any application which mixes X and PostScript imaging models with separate connections. This is why I believe that DPS's approach is the correct one (independent of the details; I haven't programmed it, so reserve judgement as to whether the interfaces are well done) and X11/NeWS merged server is incorrect, as I understand the two approaches. Of course, you could do the X extension in reverse (X inside the NeWS protocol); that would be equivalent, but two separate connections seem to be generating really great problems for anyone who wants to mix imaging models, and a fundamental problem with the approach. >>And as to the rest of your message, isn't Shearson the brokerage house that >>has taken a big interest in Sun Microsystems? Or is it one of the other >>ones? >> - Jim > My apologies; done in a moment of weakness, regretted immediately. - Jim -- Digital Equipment Corporation Cambridge Research Laboratory
lemke@ncd.COM (Dave Lemke) (11/13/90)
From: uunet!fis1138.govt.shearson.com!fgreco (Frank Greco) Date: Tue, 13 Nov 90 13:43:55 EST > > 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. because the two different protocols are coming over two different connections. the xnews server treats them as two different clients, and makes no guarentees about the order in which their requests are processed. its the same problem as two X clients drawing to the same window -- its server dependent which one draws first. and this can be a major problem if you're using destructive rop codes, or overlapping graphics. I guess DEC wouldn't have the same problem mixing Display PostScript and Xlib...;-> right. because all the requests come over the same connection, from the same client, and are therefore guarenteed to be handled in a predictable order. Dave
fgreco@fis1138.GOVt.shearson.COM (Frank Greco) (11/14/90)
> > 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...;-> > > I personally agree that it would be very nice to have a common X PostScript > extension, that would work no matter what the implementation of X, so that > applications programmers could count on it. If everyone could count on it, doesn't that imply that PostScript rendering will be added to the X server? It would be nice if it wasn't an extension. However, what are the legal/business ramifications with Adobe in this matter? Are they going to allow us to us a printer PS or a display PS interface for free? Maybe Paul Asente could answer this... > > And as to the rest of your message, isn't Shearson the brokerage house that > has taken a big interest in Sun Microsystems? Or is it one of the other > ones? > - Jim > > My comments are my own and do not involve my client, Lehman Brothers at all. They are my own comments (I am an independent contractor) and do not reflect any of my clients' views..... I would've added my .signature that has the usual caveats, but it would waste bandwidth like I'm doing right now answering your last (surreptitious) comment. I'm sure working for DEC has not colored your opinions at all...right? Frank G. I was going to say something about snake-oil...but I won't....;->
jg@crl.dec.com (Jim Gettys) (11/14/90)
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
korp@atlantis.ees.anl.gov (Peter Korp) (11/14/90)
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...;-> Actually I think they don't! I think it is accomplished by sending PS commands as X protocol requests. Thus, no need to sync between the two imaging models. [other ramblings deleted] As I am not privy to source, exactly how is the DP extension to X implemented? Are the X proto requests interpreted by the X-server and basically converted to standard X calls? Is systemdict shared by all processes? Peter
korp@atlantis.ees.anl.gov (Peter Korp) (11/14/90)
Well this topic is getting kind of old, but.... I know that having two sockets to communicate through is kinda gross but then how often do you really want to do X imaging in the same area as PostScript? It seems that proper use of clippaths/GC would eliminate most of the problems jim refers to. I guess i'm just saying it is not a problem using two imaging models in OpenWindows. Draw X stuff stuff around PS stuff and vice-versa but why mix them? Peter ------------------------------------------------------------------------------- PostScript Raster imaging in OpenWindows in a 500x500 window? Can you say 60 frames per second? I knew you could!
jdn@europa.Eng.Sun.COM (Jeff Nisewanger) (11/15/90)
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
asente@adobe.com (Paul Asente) (11/15/90)
In article <9011131842.AA08663@islanders.> fgreco@fis1138.GOVt.shearson.COM (Frank Greco) writes: > If everyone could count on it, doesn't that imply that > PostScript rendering will be added to the X server? > It would be nice if it wasn't an extension. However, what > are the legal/business ramifications with Adobe in this matter? > Are they going to allow us to us a printer PS or a display PS > interface for free? Maybe Paul Asente could answer this... It's already there. Look in the R4 distribution under contrib/extensions/dpyPostScript and you'll find the specification of the Display PostScript extension and the .h files describing the interface from the client side. -paul asente asente@adobe.com ...decwrl!adobe!asente
asente@adobe.com (Paul Asente) (11/15/90)
In article <1990Nov14.012626.3685@mcs.anl.gov> korp@atlantis.ees.anl.gov (Peter Korp) writes: >As I am not privy to source, exactly how is the DP extension to X implemented? >Are the X proto requests interpreted by the X-server and basically converted >to standard X calls? Is systemdict shared by all processes? You don't need to be privy to source, just documentation! The way an X extension works is that each particular instance of an X server supports some number of extensions, possibly 0. The extensions that a server supports is normally determined when the server is built. (Run-time loading complicates this somewhat. The server must be able to respond to the XListExtensions request and give back all the extensions it supports, so it must know about extensions that it is willing to load.) Requests destined for an extension look exactly like normal X requests. They have a request code, length, etc. The server's event dispatcher sees these requests, notices that they are for an extension, and passes them off to the extension code. In DPS's case, what the extension does with the request is execute it as PostScript code and image into a drawable. Each X server connection that also uses DPS/X (the name for the Display PostScript extension to X) must get a PostScript execution context. The normal case is one context per display connection. Part of a PostScript execution context is a virtual memory (VM), and normally each execution context has its own VM (although they can be shared). There is also a designated VM called the shared VM, visible to all contexts. When the extension looks for something, it looks in both the private VM for the currently executing context and the shared VM. Usually a context only updates its own VM, but it can enter a mode where it can update the shared VM; an example use would be to install a new font. Systemdict lives in the shared VM. If you're interested, you can order the Display PostScript documentation binder by calling Adobe Developer Support at (415) 961-4111. -paul asente asente@adobe.com ...decwrl!adobe!asente
jg@zorch.crl.dec.com (Jim Gettys) (11/15/90)
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
asente@adobe.com (Paul Asente) (11/20/90)
In article <1990Nov15.021857.21755@crl.dec.com> jg@zorch.crl.dec.com (Jim Gettys) writes: >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. ... >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. You have to remember that the PostScript language is interpreted and allows you to redefine its operators. There's no way to know that the "lineto" operator hasn't been redefined to call a loop that runs for 10 minutes. It's inherent in the nature of the beast. Using a single connection gives you free synchronization in one direction. You can, for example, create a drawable and immediately image into it with PostScript code; no need to synchronize. If you want to know that the PostScript has completed, you must synchronize afterwards. I would argue that saying "you must always synchronize after PostScript rendering before relying upon the results for X calls" an easier rule for programmers to remember than something like "you don't need to synchronize as long as you use only built-in operators that haven't been redefined and you only use <= N of them in one call and by the way no loops and no large image manipulations that can take several seconds and no text since the font definition can contain arbitrary PostScript and..." Tim Glauert presented a synchronization extension at the EXUG conference earlier this fall. This would be just the thing for DPS/X since it would allow the synchronization to take place in the server without round trips. You would be able to say, "Don't execute any more requests on this input stream until the PostScript code completes." I hope it gets picked up by the Consortium for R5. -paul asente asente@adobe.com ...decwrl!adobe!asente
kent@Xerox.com (Chris Kent) (11/20/90)
Well well. Ignore news for a few weeks and see what happens! I'm surprised no one else has answered definitively yet, to tell the truth. The answer is that you're both right. To really, truly synchronized the DPS extension and X primitives, you need to use DPSWaitContext (or the clientsync operator, depending on which way you're trying to force the synchronization). But unless you're counting on the results of some PostScript operation, you probably never need to synchronize explicitly, because the painting operators execute very quickly. An example of a place you must synchronize is if you're using DPS operations to image into a pixmap, and then want to look at the contents of the pixmap (say, with GetImage or CopyArea). In that case, doing a WaitContext is necessary to make sure that the contents of the pixmap are complete before copying the bits away. This is unfortunate, perhaps, but programmers usually get around this by creating the pixmaps once, ahead of time, and then just doing the CopyAreas when the bits are needed during program execution. So yes, Jim, the extension follows your rule of least astonishment: if you do a DrawLine followed by a show, the text gets rendered second. But, if you do DrawLine/show/DrawLine, the second line may get painted before the text has finished painting, depending on a whole bunch of things (mainly whether or not the characters are in the cache, if the font has been run before, and so on). In some cases, this will matter. In most, it won't. But there's another advantage of having a single connection and having DPS a real part of X, rather than in a separate environment with a separate connection: sharing of resources and resource IDs. Some of the DPS operators know about X resource IDs, so you can do things like change the gc and drawable with a DPS operator. In particular, the gc and drawable are part of the graphics state that is saved by gstate or the user graphics state operators. This makes using a single context to display output on several drawables very easy. Hope that clears things up a bit. chris
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (11/21/90)
[about DPS-versus-NeWS and synchronization] >> 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 [...]. > You have to remember that the PostScript language is interpreted and > allows you to redefine its operators. There's no way to know that > the "lineto" operator hasn't been redefined to call a loop that runs > for 10 minutes. It's inherent in the nature of the beast. So? If I've done this and I call lineto, I expect the connection I do it on to be blocked for ten minutes. If I want to run it asynchronously I'll explicitly "fork" a "process" to do it. (Quotes because the terms don't have quite their usual UNIX-style meanings.) > I would argue that saying "you must always synchronize after > PostScript rendering before relying upon the results for X calls" an > easier rule for programmers to remember than something like "you > don't need to synchronize as long as you use only built-in operators > that haven't been redefined and you only use <= N of them in one call > and by the way no loops and no large image manipulations that can > take several seconds and no text since the font definition can > contain arbitrary PostScript and..." Well yes. But compare it with "you don't need to synchronize unless you told it to run asycnhronously". I would say that least surprise requires that the default be synchronous, and that the little argument we've just had here bears me out. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
flar@bendenweyr.Eng.Sun.COM (Jim Graham) (11/22/90)
Why isn't there an extension protocol request which blocks the execution of additional requests from the extension until the PostScript is finished? Why is a return packet needed to synchronize the two? I should be able to execute the following: Xrequest1 Xrequest2 XDPSrequest Xrequest3 XDPSsynch Xrequest4 Xflush() None of the requests need a reply, so they continue to be buffered until I execute the Xflush() at the end. The Xrequest3 ends up executing asynchronously (let's assume that I knew ahead of time that it would be independent of the results of the XDPSrequest). Then the synch holds up the connection until the PostScript is done. Finally the Xrequest4 gets executed after the DPS stuff is done. None of this required a return packet, all it required was one more protocol request. ...jim