Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!whuts!mtune!rutgers!cmcl2!nrl-cmf!ames!sgi!decwrl!granite!rost From: rost@granite.dec.com (Randi Rost) Newsgroups: comp.windows.x Subject: Re: X Conference notes Summary: Correcting misimpressions of PEX Message-ID: <181@granite.dec.com> Date: 26 Jan 88 22:57:07 GMT References: <8801221812.AA19881@> Organization: Digital Equipment, WSE group, Palo Alto, CA Lines: 39 To anyone who read Paul Raveling's trip report: I just wanted to clear up a couple of misimpressions about the PEX (3D) extension for X. The first potentially misleading statement in the report is: "A PHIGS window is EXCLUSIVELY PHIGS; external X access is not practical." If I'm reading this correctly, the statement is untrue. If other people got the same impression from the presentation, we hosed it badly (please tell us what we said to give you this impression). In X, a window is just a "bucket of bits" that can be scribbled on. PEX does not change this definition at all, but introduces a resource called a "renderer" that is capable of doing PHIGS-style scribbling into an X window. Therefore, it is still entirely possible to draw PEX output primitives and X output primitives into the same window. Secondly, the statement "The X extension [PEX] should support 3D, but the speaker anticipates most use will be (efficient) 2D." can also be misleading. During the presentation, Marty stated his opinion that PEX would be used more for 2D applications (same coordinate systems but the default z-value is always assumed) than for 3D applications. I, for one, am not convinced that this will be true, but it is beside the point. THE DESIGN FOCUS FOR PEX WAS TO PROVIDE EFFICIENT SUPPORT FOR *3D*, PHIGS/PHIGS+ STYLE RENDERING. Support for 2D falls out as a special case of 3D (z is constant). Whether there will eventually be more 2D applications layered on top of PEX than 3D applications is a moot point. PEX was designed for efficient 3D support. Randi Rost Digital Equipment Corp. PEX Architecture Team