🚀 go-pugleaf

In article <1992Aug14.210903.23864@noose.ecn.purdue.edu>
	John Lu <luj@ecn.purdue.edu> writes:
>The biggest plus of the PHIGS(+) seems to be the fact that it is
>an international standard. [...] When will PHIGS/PHIGS PLUS incorporate
>those requirements [anti-aliasing, texture-mapping] so that one can be
>_guranteed_ to have portablity and uniformity ?  

Oh, I guess I mis-parsed your previous statement.  When you said
"PHIGS/PHIGS-PLUS can never speed up", were you referring to the speed
of an implementation (what I thought), or the speed of the standards
process?  As I mentioned in another note, there is no need to take the
slow route through the standards process to implement these features
in a portable and uniform way.  All the things you ask for can be
brought about through registration:

    GSEs to control anti-aliasing effects
    data mapping method records to control texture mapping (the
	primitives can already contain arbitrary per-vertex data, so
	there is no need to get a new primitive approved to support
	per-vertex texture coordinates)

I was incorrect when I stated earlier that registration didn't require
a vote; it does require a vote, but the process is much faster than
changing the standard.  A registration proposal can probably be
approved into the standard within the same time it would take for
other vendors to implement the registered feature in the next release
of their software products.

I said:
>|> Given any particular API or
>|> programming model, its possible to create a hardware/software
>|> combination that will run fast.

>That's why I was saying that PEX can probably catch up to support those
>functionalities, though I'm not sure when the complete _inter-operability_
>can be achieved.

Complete interoperability is functionally here right now.  Under the
PHIGS model, registration allocates positive identifiers to registered
items.  Implementation-specific items use negative identifiers.  Under
PEX, they extended this concept even further by subdividing the
negative name-space of the identifiers into intervals assigned to each
vendor.  Thus, when a PEX server encounters a GSE, it can determine
the (vendor,GSE) pair that indicates what the server should do (if
possible) to simulate/emulate the GSE.  This is how the extensions
provided in PEX by different vendors can be allowed to interoperate
_before_ they are registered officially with PEX/PHIGS.  Note also,
the PEX is not an ANSI/ISO standard, but an X Consortium Standard.
I believe (correct me if I'm wrong, Jay) that there is a registration
process for PEX as well, probably considerably shorter than for PHIGS.

>If PEX spec chooses to be more strigent 
>and to eliminate the subset problems,

Many people are pushing for elimination of subsets in 6.0.

>then PEXlib can probably supercede the PHIGS API to compete with the OpenGL.

Personally, I think statements like this are misleading.  The PHIGS
API is not the limiting factor in obtaining performance, so using it
should be a matter of choice and not necessity.  I don't think PEXlib
is going to be a popular API for applications, but will be a popular
SPI (systems programming interface) for 3D toolkits that simplify the
generation of 3D graphics for the applications programmer.

>|> [...] What users care about is performance available to their
>|> application, not just a peak number of for a contrived or pathological case
>|> of data. 
>
>As a user in the area of general-purpose computing, I can the performance 
>as well as the portability of my applicaton software. 
>Given a certain PHIGS implementation having
>non-standard extension, how is the portability  guranteed ?

Portability has always been a not-easily obtained goal in graphics.  X
is supposed to be portable, but I can't tell you how many programs
don't run in an environment different from the one in which they were
generated.  It seems that many people just can't be bothered with
searching the list of visuals to find the right one, etc.

Graphics applications are typically attempting to squeeze out all they
can from the hardware in order to obtain interactivity.  The level at
which one programs in order to obtain interactivity is much different
between a workstation and a 386 IBM/clone.  The bottom line for
interactivity is knowing the capabilities of the device and
programming to them.  This is completely at odds with portability,
which attempts to know almost nothing about the device's particular
capabilities.

>My points are:
>	1). PHIGS standard promises the portability. However, due to
>the lack of advanced features in the PHIGS and the nonstandard extensions 
>from differnt PHIGS implemations, the highly expected portablity is lost.

Someone else mentioned to me that standards codify accepted practice.
"Advanced features" are, by definition, not accepted practice.  The
majority of CAD/CAM users out there don't need motion blur.  Of
course, in an industry as dynamic and changing as computer graphics,
what is "accepted practice" can change quite quickly.  For many,
portability has always meant coding to the least-common denominator.
This has always come at the expense of some feature set.

>	2). It is quite evident that the PHIGS API has _much_ room to desire.

Quite evident to you perhaps.  Others may disagree.  Its important to
make the distinction between fact and opinion.  The above is clearly
your opinion.

>	3). I certainly do not expect that my graphics application have the
>same performace on all the plateforms. However, I do want my applications to 
>run on as many plateforms as possible.

If your application requies interactivity, and not just static
renderings, then the performance will be critical to the usefulness of
the application.  Attempting to interactively manipulate 10,000
polygons on an underpowered machine is going to be so frustrating as
to make the application useless.

>I also expect that the application have a high performance on a high-end
>workstation yet be able to run a low-end box. 
>OpenGL seems to have solved this this problem.

Again, there is a difference between "being able to run" and running
usefully.  OpenGL doesn't make 386 PCs, or any other low-end machine,
run things faster.

>Yes, there is _always_ the need for data reformating, but one wants to
>avoid this as much as possible.

Under OpenGL, the same reformatting happens; you merely get what
language designers call "syntactic sugar" so that you can provide the
data in any datatype you wish.  However, at the core of all graphics
rendering today (at least the PEX/OpenGL type) is a graphics pipeline.
Data goes in one side and pixels come out the other (I'm
oversimplifying).  This pipeline is going to have its own natural data
format for the data that is the most efficient for its algorithms.
Your data will be reformatted to this internal representation.

>In PHIGS and PEXlib, data reformating is almost essential, it is ubiquitous.

PEXlib is not intended to be an API, but an SPI.  If you want the
same syntactic sugar that is provided in OpenGL, you can write a
toolkit on top of PEXlib that does this reformatting for you.

>I do have some boxes running PEX-SI

If possible, I recommend you get a PEX server from your workstation
vendor instead of the PEX-SI.  The SI is, after all, a Sample
Implementation, and can't be expected to run blazingly fast or provide
a gigantic feature set.

						-- Rich
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer