raveling@VAXA.ISI.EDU (Paul Raveling) (01/23/88)
Should any (presumably) non-attendees be interested, I've prepared some conference notes with more detail than what's appeared so far. The file's about 40K bytes, ~30 pages when printed. This is still brief enough to serve mainly as a commented index to the videotape. If there's enough interest I'll put it someplace accessible to anonymous ftp. (Would XUG have a home for this sort of thing?) --------------------- Paul Raveling Raveling@vaxa.isi.edu
raveling@VAXA.ISI.EDU (Paul Raveling) (01/23/88)
It appears there's enough interest, so the X conference notes I mentioned this morning are available now via anonymous ftp. Their location is: host: vaxa.isi.edu path: pub/X/xconference.notes For those without ftp access, I MIGHT be able to mail it as a message. However, something in the path of my outgoing mail loves to rewrite non-ARPANET addresses into an undeliverable form, so there are no guarantees. --------------------- Paul Raveling Raveling@vaxa.isi.edu
rost@granite.dec.com (Randi Rost) (01/27/88)
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 Teamturner@daisy.UUCP (Jim Turner) (01/28/88)
To those of use poor fools without arpanet access, you can get a copy of
the conference notes by sending email to:
...ucbvax!sgi!daisy!XArchive-request
please specify what you want (the conference notes)
--
Laissez les bons temps rouler - Queen Ida
...{decwrl|ucbvax}!imagen!atari!daisy!turner (James M. Turner)
Daisy Systems, 700 E. Middlefield Rd, P.O. Box 7006,
Mountain View CA 94039-7006. (415)960-0123raveling@vaxa.isi.edu (Paul Raveling) (01/30/88)
In article <181@granite.dec.com> rost@granite.dec.com (Randi Rost) writes: > >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 this is substantially misleading, I apologize for the mis-statement. Both the talks and the notes necessarily condensed lots of material into perhaps excessively brief remarks. Also, I was doing a little "reading between the lines" by relating the PEX architecture to issues (a euphemism for problems) we encountered in work directed toward supplying an integrated user interface for existing software. The most relevant issues arose in connection with our Geographic Display Agent, and at first sight it would appear that variants of these would affect mixing separate X and PEX i/o in the same window. Briefly, some of the biggest problems in our X10.4-based experience were ... -- Inability to direct particular X events for a given window to different processes, each with its own connection to the display server. -- Use of nonlinear world coordinates in a map window showing a Mercator projection, with only linear coordinates available to external software which annotates the map. -- Automatic declutturing of various objects in the map by the Geographic Display Agent and automatic modification of specified latitude/longitude limits to suit window geometry. So far our solution is to encapsulate all map window manipulation within the GDA. I'll be interested to see how PEX solves the various problems of input and X event multiplexing, and of sharing sufficient knowledge of the image it generates with an external software component. --------------------- Paul Raveling Raveling@vaxa.isi.edu
vidal@ctt.bellcore.com (Vidal Graupera) (01/30/91)
Could someone forward me a copy of the notes to the tutorial "X Sample Server Internals" which was given by Keith Packard at the recent X Technical Conference? Either electronic or paper version would be fine. Thanks, Vidal Graupera Bellcore RRC 1E230 444 Hoes Lane Piscataway, NJ 08854 email: vidal@ctt.bellcore.com P.S. What was the total attendance at the conference?