home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!news.bbn.com!usc!cs.utexas.edu!sun-barr!ames!purdue!mentor.cc.purdue.edu!noose.ecn.purdue.edu!ecn.purdue.edu!luj
- From: luj@ecn.purdue.edu (John Lu)
- Newsgroups: comp.windows.x.pex
- Subject: Re: Future development of PEX/PHIGS
- Message-ID: <1992Aug14.210903.23864@noose.ecn.purdue.edu>
- Date: 14 Aug 92 21:09:03 GMT
- References: <1992Aug13.170434.18221@hsr.no> <1992Aug13.221534.29469@noose.ecn.purdue.edu> <1992Aug14.172943.22563@dsd.es.com>
- Sender: luj@ecn.purdue.edu (Jun Lu)
- Reply-To: luj@ecn.purdue.edu
- Organization: Purdue University Engineering Computing Network
- Lines: 107
-
- In article <1992Aug14.172943.22563@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
- |>
- |> In article <1992Aug13.221534.29469@noose.ecn.purdue.edu>
- |> luj@ecn.purdue.edu writes:
- |> >I guess that PHIGS/PHIGS PLUS can never speed up to support
- |> >what you're demanding.
- |>
- |> Can you please cite some facts to back up this assertion?
-
- The biggest plus of the PHIGS(+) seems to be the fact that it is
- an international standard. Therefore one can expect to gain the portability
- and performance across different hardware/software implementations. However, the
- standard lacks many functionalities(e.g. immediate mode, anti-aliasing,
- transparency, shadows, texture mapping ...) that users demand. True, some
- PHIGS implementation do support these functionalities. But the portability
- that one highly expects is gone. When will PHIGS/PHIGS PLUS incorporate
- those requirements so that one can be _guranteed_ to have portablity and
- uniformity ?
-
-
- |> We've been
- |> all over this before in this group. Given any particular API or
- |> programming model, its possible to create a hardware/software
- |> combination that will run fast. Our PEX servers regularly beat the
- |> pants off any other PEX server on the market. The Graphics
- |> Performance Characterization Committee of the NCGA has a standard
- |> suite of benchmarks used to evaluate the performance of different
- |> vendor's platforms. The Picture Level Benchmark is, in concept,
- |> similar to the SPEC suite of applications for measuring CPU
- |> performance.
- |>
-
- 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. If PEX spec chooses to be more strigent
- and to eliminate the subset problems, then PEXlib can probably supercede
- the PHIGS API to compete with the OpenGL.
-
-
- |> [...] 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 ?
-
-
- |>
- |> >By the time it did, another much better API would
- |> >have probably widely accepted.
- |>
- |> Wrong. Performance is easily obtained through PEX, but I'll give
- |> you a hint: you won't get it through a software renderer. In order to
- |> do graphics fast, you need hardware. I don't see anything changing
- |> that statement. Of course, the details of the hardware (architecture,
- |> clock speed, buffering, etc) are changing all the time, but I've yet
- |> to see a software renderer that can outperform hardware.
- |>
-
- Never have I claimed that the software renderer will outperform the H/W.
- 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.
- 2). It is quite evident that the PHIGS API has _much_ room to desire.
- I was quite dismayed when I saw the phigs bindings at the first time. It is
- quite possible other API's such as PEXlib, OpenGL or yet to be designed API
- will be the one of choice.
- 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. 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. PEX's inter-operatbility and
- subset problems are yet to be resolved. I certaily hope that the above PEX problems
- can be resolved soon so that an application programmer can use much more elegant API such
- as PEXlib intead of the PHIGS API.
-
-
- |>
- |> >I seem to have been convinced by Alan Akin that OpenGL superior to PEX
- |> >in that there is little need in reformatting the application's data
- |> >structure for graphics.
- |>
- |> Unless your graphics hardware can accept all varieties of data
- |> types for specifying geometry and associated information, there will
- |> always be some reformatting.
-
- Yes, there is _always_ the need for data reformating, but one wants to avoid this
- as much as possible. In PHIGS and PEXlib, data reformating is almost essential,
- it is ubiquitous.
-
- |> the network is still not the
- |> bottleneck. The system bus and the speed of the graphics hardware is
- |> still the bottleneck
-
- I don't know much about this, someone else should be able to anwser this.
- I have to admit that this is quite a suprise to me.
-
- --
- -- John Lu
- luj@ecn.purdue.edu
-
-
- Disclaimer: SGI has decided not to support the OpenGL for the SGI mahine I am running.
- I do have some boxes running PEX-SI, though.
-