gds@atticus (Greg Schechter) (03/19/91)
In article <1991Mar17.235026.4718@dsd.es.com>, rthomson@mesa (Rich Thomson) writes: >PEX is PHIGS/PHIGS-PLUS Extensions to X, so if they are using PEX they >are using PHIGS (at least for output -- PEX doesn't attempt to cover >PHIGS style input on the server side; input happens through a beast >called the "PHIGS Monitor" which runs as a separate process that >interacts with a PHIGS client program). > >So, if you are using PEX you are using PHIGS. > Actually, this is not true. PEX is simply a protocol, just like X. However, it is an extension to the core X protocol. It simply relates specific byte encodings to specific server actions on the part of the PEX extended server. It just so happens that PEX was designed specifically to support the functionality that PHIGS and PHIGS PLUS offer, but it is not an Application Programming Interface. Saying PEX uses PHIGS is like saying X uses XView or the Athena Widgets. On the other hand, distributed implementations of PHIGS may use PEX to achieve their distributivity. This is particularly true if a PHIGS implementation wants to be able to communicate with a variety of vendors' window servers. For example, a PHIGS implementation running on a Sun may open PHIGS workstations on the local Sun, a remote Sun running a PEX server, and a remote 3rd party machine running a PEX server. -- Greg ============================================================================= = Greg Schechter Graphics Technology Group = = Sun Microsystems, Inc Mailstop MTV21-04 = = 2550 Garcia Avenue Mountain View, CA = = gschechter@Eng.Sun.COM (415) 336-6950 = =============================================================================
cpetterb@es.com (Cary Petterborg) (03/19/91)
In article <10030@exodus.Eng.Sun.COM> gds@atticus (Greg Schechter) writes: > In article <1991Mar17.235026.4718@dsd.es.com>, rthomson@mesa (Rich Thomson) writes: > >PEX is PHIGS/PHIGS-PLUS Extensions to X, so if they are using PEX they > >are using PHIGS (at least for output -- PEX doesn't attempt to cover > >PHIGS style input on the server side; input happens through a beast > >called the "PHIGS Monitor" which runs as a separate process that > >interacts with a PHIGS client program). > > > >So, if you are using PEX you are using PHIGS. > > > Actually, this is not true. PEX is simply a protocol, just like X. > However, it is an extension to the core X protocol. It simply relates > specific byte encodings to specific server actions on the part of the > PEX extended server. It just so happens that PEX was designed > specifically to support the functionality that PHIGS and PHIGS PLUS > offer, but it is not an Application Programming Interface. <stuff deleted> > -- Greg Note what Rich says, "if you are using PEX you are using PHIGS." He is correct in this because currently there is no other application interface to PEX, but PHIGS. Using PEX (the extensions to X, not X) implies that you are dealing with the extensions that are only available through PHIGS, unless you are crazy enough to set up the protocol packet yourself. (not a good idea unless you REALLY know what you are doing) Cary -- _______________ Cary Petterborg (801)582-5847 x6446 Evans & Sutherland Computer Corp. Simulation Division SLC, UT 84108 USENET: utah-cs!esunix!cpetterb INTERNET: cpetterb@esunix.es.com
rthomson@mesa.dsd.es.com (Rich Thomson) (03/20/91)
In article <1991Mar17.235026.4718@dsd.es.com>, I said: :So, if you are using PEX you are using PHIGS. In article <10030@exodus.Eng.Sun.COM> gds@atticus (Greg Schechter) writes: >Actually, this is not true. PEX is simply a protocol, just like X. I have had this discussion via e-mail with Spencer Thomas (who could be considered a PEX 'guru') already. There are several confusing issues here: o PHIGS/PHIGS-PLUS (Usually when one says "PHIGS", they mean both PHIGS and PHIGS-PLUS [PLUS = ``Plus Lumiere Und Surfaces'' which gives you lighting and shading]) PHIGS is defined via a set of abstract functions and associated semantics. The standard only defines these, language bindings determine the API. Currently there are DIS (draft international standard) bindings for C and there is an approved binding for FORTRAN. [I am recalling this from memory, but I believe it to be correct; if it isn't, I'm sure some astute news reader will correct me ;-] o PEX PEX is the PHIGS Extensions to X. Seems to me that the very name implies that PEX is PHIGS. Like most extensions to X, PEX has two sides: the client side and the server side. The core of the extension is really the protocol as Greg points out, but in reality PEX means alot more to users than just the protocol. It is possible to write programs using only the protocl definition, but this is painful at best. In server land, the PEX protocl is implemented via a number of resources that provide some basic functionality. The document ``PEX Introducion and Overview'', version 3.20, dated 8 June 1989 starts as follows: ``PEX (a PHIGS/PHIGS+ Extension for X) is a 3D graphic extension to the X Window System(*) that efficiently supports PHIGS and PHIGS+.'' (*) X Window System is (TM) by MIT. That indicates to me that no matter how you are encoding the protocol, you are using PHIGS. That is to say that in the server, PEX implements the functionality and semantics defined by the PHIGS and PHIGS-PLUS standards. Now by virtue of the PEX implementation, it is possible to do things not defined by the functionality of PHIGS. In particular, it is possible to do immediate-mode style rendering if your server extension fully supports the PEX protocol and you have some way of generating these protocol packets. In particular, the idea of using a ``Renderer'' (instead of a PHIGS workstation) resource covers this idea. Jan Hardenbergh of Stardent has been working on a proposed API interface to this portion of the protocol (the API is collectively called PEXIM for PEX Immediate Mode). In client land, the protocol is generated by the API. It doesn't matter if your API looks like the QuickDraw, PostScript, SGI's GL, or whatever. The server is *still* going to interpret those protocol requests according to PHIGS/PHIGS+ functionality and semantics. If it doesn't, then its not PEX, but some homebrew 3D extension to X. Given this preliminary explanation of how I am using these terms, Greg says: >However, it is an extension to the core X protocol. It simply relates >specific byte encodings to specific server actions on the part of the >PEX extended server. It just so happens that PEX was designed >specifically to support the functionality that PHIGS and PHIGS PLUS >offer, but it is not an Application Programming Interface. Correct. The PEX protocol is not an API, but PEX as distributed by the SI does include an API based on the DIS C binding for PHIGS/PHIGS-PLUS. I think we're just quibbling about what is meant when one says "PEX". I take it to mean both the client-side API that generates the protocol requests and the server-side extensions that implement the requests. So far, I've not seen a special name for the client-side portion. >Saying PEX uses PHIGS is like saying X uses XView or the Athena >Widgets. See above. Given that PEX implements the functionality and semantics of PHIGS, I believe it is correct to say that PEX uses PHIGS. Again, it doesn't matter what API you have, the rendering is still done according to PHIGS functionality and semantics specifications. From documents originating with the PEX architecture team and SI team, this has always been clear to me. >On the other hand, distributed implementations of PHIGS may use PEX to >achieve their distributivity. This is particularly true if a PHIGS >implementation wants to be able to communicate with a variety of >vendors' window servers. For example, a PHIGS implementation running >on a Sun may open PHIGS workstations on the local Sun, a remote Sun >running a PEX server, and a remote 3rd party machine running a PEX >server. Again, I think you're confusing the API (language binding in ANSI jargon) with PHIGS (the standard). -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
cn09+@andrew.cmu.edu (Christopher Kalevi Nuuja) (03/21/91)
I know that the dec and sun implementations of phigs+ (not phigs) are so
different from each other that we needed to write 2 different device drivers
for an application we are working on. Does anyone know if PEX conforms to
sun or dec phigs+ programmer interfaces, or is it also another flavor of
the non-standard?
(p.s. Standard phigs is identical in both the sun and dec implementations,
but without lightsources, it is useless).gds@atticus (Greg Schechter) (03/21/91)
cpetterb@es.com (Cary Petterborg) writes: > Note what Rich says, "if you are using PEX you are using PHIGS." He > is correct in this because currently there is no other application > interface to PEX, but PHIGS. Using PEX (the extensions to X, not X) > implies that you are dealing with the extensions that are only available > through PHIGS, unless you are crazy enough to set up the protocol packet > yourself. (not a good idea unless you REALLY know what you are > doing) But this is only a temporary situation. Presumably, other application interfaces will soon be ported so as to emit the PEX protocol. Potential candidates for this are GKS, Sun's XGL, SGI's GL, HP's Starbase, Stardent's Dore, and most other non-pixel-based graphics packages. In article <1991Mar19.211031.29928@dsd.es.com>, rthomson@mesa (Rich Thomson) writes: > o PEX > PEX is the PHIGS Extensions to X. Seems to me that the very > name implies that PEX is PHIGS. Like most extensions to X, > PEX has two sides: the client side and the server side. The > core of the extension is really the protocol as Greg points > out, but in reality PEX means alot more to users than just the > protocol. It is possible to write programs using only the > protocl definition, but this is painful at best. > > In server land, the PEX protocl is implemented via a number of > resources that provide some basic functionality. The document > ``PEX Introducion and Overview'', version 3.20, dated 8 June > 1989 starts as follows: > > ``PEX (a PHIGS/PHIGS+ Extension for X) is a 3D graphic > extension to the X Window System(*) that efficiently > supports PHIGS and PHIGS+.'' > > (*) X Window System is (TM) by MIT. > > That indicates to me that no matter how you are encoding the > protocol, you are using PHIGS. To me, this indicates that if you're using PEX, you're using a protocol that was designed to efficiently support PHIGS, but not that you're using PHIGS itself. > That is to say that in the > server, PEX implements the functionality and semantics defined > by the PHIGS and PHIGS-PLUS standards. There are many things in PHIGS and PHIGS PLUS which cannot be done via PEX. Some of these are input (PHIGS has a very rich input model, PEX has non), archiving (PEX knows nothing about archiving), and the PHIGS PLUS color mapping semantics (the semantics of the PEX color mapping is quite different). I guess the problem that I have with the statement "If you're using PEX, you're using PHIGS" is that it suggests that if I've got a machine with a PEX server on it, I somehow have access to PHIGS. This is just not true. You need to have a PHIGS library which implements these other things that PEX does not provide, and which also provides a language binding for the features that the server has built in to it. >>On the other hand, distributed implementations of PHIGS may use PEX to >>achieve their distributivity. This is particularly true if a PHIGS >>implementation wants to be able to communicate with a variety of >>vendors' window servers. For example, a PHIGS implementation running >>on a Sun may open PHIGS workstations on the local Sun, a remote Sun >>running a PEX server, and a remote 3rd party machine running a PEX >>server. >Again, I think you're confusing the API (language binding in ANSI >jargon) with PHIGS (the standard). How so? --- Greg ============================================================================= = Greg Schechter Graphics Technology Group = = Sun Microsystems, Inc Mailstop MTV21-04 = = 2550 Garcia Avenue Mountain View, CA = = gschechter@Eng.Sun.COM (415) 336-6950 = =============================================================================
pmartz@undies.dsd.es.com (Paul Martz) (03/22/91)
In article <IbtvaM200WB6Q8_nZI@andrew.cmu.edu>, cn09+@andrew.cmu.edu (Christopher Kalevi Nuuja) writes: > I know that the dec and sun implementations of phigs+ (not phigs) are so > different from each other that we needed to write 2 different device drivers > for an application we are working on. Does anyone know if PEX conforms to > sun or dec phigs+ programmer interfaces, or is it also another flavor of > the non-standard? > > (p.s. Standard phigs is identical in both the sun and dec implementations, > but without lightsources, it is useless). Well, the language binding over PEX could be either. But I think what you're asking is, "what's the PEX-SI language binding for phigs+ going to look like?" Well, it looks like the latest DIS C language binding. ("pset_line_color", for example, is the binding for the SET POLYLINE COLOUR function.) This is different from the last version of SunPhigs I saw, and I've never seen DecPhigs, so I don't know what version of the binding they currently use. The latest DIS that the PEX-SI is using (and will be shipped with X11R5) is dated 24 November 1990. Hopefully this will be standardized soon. It's killing those of us with products based on it, and it's driving customers and users crazy. -- -paul pmartz@dsd.es.com Evans & Sutherland