home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / windows / x / pex / 459 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  5.4 KB

  1. 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
  2. From: luj@ecn.purdue.edu (John Lu)
  3. Newsgroups: comp.windows.x.pex
  4. Subject: Re: Future development of PEX/PHIGS
  5. Message-ID: <1992Aug14.210903.23864@noose.ecn.purdue.edu>
  6. Date: 14 Aug 92 21:09:03 GMT
  7. References: <1992Aug13.170434.18221@hsr.no> <1992Aug13.221534.29469@noose.ecn.purdue.edu> <1992Aug14.172943.22563@dsd.es.com>
  8. Sender: luj@ecn.purdue.edu (Jun Lu)
  9. Reply-To: luj@ecn.purdue.edu
  10. Organization: Purdue University Engineering Computing Network
  11. Lines: 107
  12.  
  13. In article <1992Aug14.172943.22563@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
  14. |> 
  15. |> In article <1992Aug13.221534.29469@noose.ecn.purdue.edu>
  16. |>     luj@ecn.purdue.edu writes:
  17. |> >I guess that PHIGS/PHIGS PLUS can never speed up to support 
  18. |> >what you're demanding.
  19. |> 
  20. |> Can you please cite some facts to back up this assertion? 
  21.  
  22. The biggest plus of the PHIGS(+) seems to be the fact that it is
  23. an international standard. Therefore one can expect to gain the portability
  24. and performance across different hardware/software implementations. However, the
  25. standard lacks many functionalities(e.g. immediate mode, anti-aliasing,
  26. transparency, shadows, texture mapping ...) that users demand.  True, some
  27. PHIGS implementation do support these functionalities.  But the portability
  28. that one highly expects is gone. When will PHIGS/PHIGS PLUS incorporate
  29. those requirements so that one can be _guranteed_ to have portablity and 
  30. uniformity ?  
  31.  
  32.  
  33. |> We've been
  34. |> all over this before in this group.  Given any particular API or
  35. |> programming model, its possible to create a hardware/software
  36. |> combination that will run fast.  Our PEX servers regularly beat the
  37. |> pants off any other PEX server on the market.  The Graphics
  38. |> Performance Characterization Committee of the NCGA has a standard
  39. |> suite of benchmarks used to evaluate the performance of different
  40. |> vendor's platforms.  The Picture Level Benchmark is, in concept,
  41. |> similar to the SPEC suite of applications for measuring CPU
  42. |> performance.
  43. |> 
  44.  
  45. That's why I was saying that PEX can probably catch up to support those
  46. functionalities, though I'm not sure when the complete _inter-operability_
  47. can be achieved.  If PEX spec chooses to be more strigent 
  48. and to eliminate the subset problems, then PEXlib can probably supercede
  49. the PHIGS API to compete with the OpenGL.
  50.  
  51.  
  52. |> [...] What users care about is performance available to their
  53. |> application, not just a peak number of for a contrived or pathological case
  54. |> of data. 
  55.  
  56. As a user in the area of general-purpose computing, I can the performance 
  57. as well as the portability of my applicaton software. 
  58. Given a certain PHIGS implementation having
  59. non-standard extension, how is the portability  guranteed ?
  60.  
  61.  
  62. |> 
  63. |> >By the time it did, another much better API would
  64. |> >have probably widely accepted.
  65. |> 
  66. |> Wrong.  Performance is easily obtained through PEX, but I'll give
  67. |> you a hint: you won't get it through a software renderer.  In order to
  68. |> do graphics fast, you need hardware.  I don't see anything changing
  69. |> that statement.  Of course, the details of the hardware (architecture,
  70. |> clock speed, buffering, etc) are changing all the time, but I've yet
  71. |> to see a software renderer that can outperform hardware.  
  72. |> 
  73.  
  74. Never have I claimed that the software renderer will outperform the H/W. 
  75. My points are:
  76.     1). PHIGS standard promises the portability. However, due to
  77. the lack of advanced features in the PHIGS and the nonstandard extensions 
  78. from differnt PHIGS implemations, the highly expected portablity is lost.
  79.     2). It is quite evident that the PHIGS API has _much_ room to desire.
  80. I  was quite dismayed when I saw the phigs bindings at the first time. It is 
  81. quite possible other API's such as PEXlib, OpenGL or yet to be designed API
  82. will be the one of choice.
  83.     3). I certainly do not expect that my graphics application have the same 
  84. performace on all the plateforms. However, I do want my applications to 
  85. run on as many plateforms as possible. I also expect that the application
  86. have a high performance on a high-end workstation yet be able to run a low-end box. 
  87. OpenGL seems to have solved this this problem. PEX's inter-operatbility and 
  88. subset problems are yet to be resolved.  I certaily hope that the above PEX problems
  89. can be resolved soon so that an application programmer can use much more elegant API such 
  90. as PEXlib intead of the PHIGS API.
  91.  
  92.  
  93. |> 
  94. |> >I seem to have been convinced by Alan Akin that OpenGL superior to PEX
  95. |> >in that there is little need in reformatting the application's data
  96. |> >structure for graphics.
  97. |> 
  98. |> Unless your graphics hardware can accept all varieties of data
  99. |> types for specifying geometry and associated information, there will
  100. |> always be some reformatting.
  101.  
  102. Yes, there is _always_ the need for data reformating, but one wants to avoid this
  103. as much as possible. In PHIGS and PEXlib, data reformating is almost essential,
  104. it is ubiquitous.
  105.  
  106. |>  the network is still not the
  107. |> bottleneck.  The system bus and the speed of the graphics hardware is
  108. |> still the bottleneck 
  109.  
  110. I don't know much about this, someone else should be able to anwser this. 
  111. I have to admit that this is quite a suprise to me.
  112.  
  113. -- 
  114. -- John Lu 
  115.    luj@ecn.purdue.edu
  116.  
  117.  
  118. Disclaimer:  SGI has decided not to support the OpenGL for the SGI mahine I am running.
  119. I do have some boxes running PEX-SI, though.
  120.