rick@pangea.Stanford.EDU (Rick Ottolini) (09/30/90)
During a visualization workshop I was running last week for the oil industry, one popular 3-D workstation vendor was knocking display-list based graphics languages such as Dore or PHIGS as being compartively inflexible and slow. This seemed to be the case for equivalent demos under the two systems. I used to be a supported of Dore/PHIGS because I thought the code was more compact and therefore quicker to debug, and now I am not so sure. Any comments?
leech@homer.cs.unc.edu (Jonathan Leech) (10/01/90)
In article <1990Sep30.060606.213@morrow.stanford.edu> rick@pangea.Stanford.EDU (Rick Ottolini) writes: >I used to be a supported of Dore/PHIGS because I thought the code was more >compact and therefore quicker to debug, and now I am not so sure. >Any comments? Display-list systems are less appropriate for dynamic databases (e.g. where the geometry is changing every frame). This will become an increasingly important issue. -- Jon Leech (leech@cs.unc.edu) __@/ "We are Buddhists. We believe in God. We also believe in Hewlett-Packard" - Kenichi Horie
thomson@cs.utah.edu (Rich Thomson) (10/01/90)
In article <1990Sep30.060606.213@morrow.stanford.edu> rick@pangea.Stanford.EDU (Rick Ottolini) writes: >[...] one popular 3-D workstation vendor was knocking display-list based >graphics languages such as Dore or PHIGS as being compartively inflexible >and slow. Well, I can guess that your ``popular 3-D workstation vendor'' was SGI because SGI systems are immediate-mode based; naturally they are going to knock display-list graphics. The fact is that there are applications in which display-list graphics have a natural fit and there are applications in which immediate-mode graphics have a natural fit. I think that the world of graphics is going to see both of these styles of graphics for quite a while. >This seemed to be the case for equivalent demos under the two systems. Again, it all depends on the application/demo you are looking at. What you find is that people who use immediate-mode systems (I'm speaking from the experience of looking at the inside of real-world applications) like them because they can have their own structured (i.e. display-list) graphics kernel that suits them. This brings up some interesting points in the case of PEX (PHIGS+ Extensions to X), because the PEX protocol provides a way for immediate-mode style graphics. In a networking environment, it can be a real advantage to have a structured graphics type approach because it isn't necessary for the application to send the entire graphics structure over the wire each time a refresh of the screen is needed. On the other hand, as a previous poster pointed out, it can be painful to deal with all the structure store of PHIGS when the entire geometry changes every frame. When this is the case the structure store isn't buying you anything. Interestingly enough, no one has decided on an "immediate-mode" language binding to the PEX protocol, yet the capability is there for those die-hards willing to talk directly to the X server over the socket. The fact of the matter is that there is no clear winner of either one: structured graphics (i.e. PHIGS, PEX) can make the job of writing a complex 3-D graphics program easier because it can do the work of managing all the attribute inheritance and structure management for you. On the other hand, with immediate-mode graphics you can control all of that yourself at the expense of writing your own "structure walker" (the piece of code that traverses the hierarchy and outputs individual graphics primitives). Again, my experience is that applications that want to see an immediate-mode interface already have some kind of structure-walker built into the application and are really doing structured graphics anyway. I find it interesting that PEX provides a way of doing both within the same framework; in that sense, I find it more flexible because I could choose which one I want to use. The sample implementation from Sun will eventually support what is called "client-side structure traversal", wherein the application will manage and traverse structure storage. This will result in *alot* of communication to the server for applications with complicated images. There is alot of talk about creating a language binding for the immediate-mode interface to PEX (built around the concept of a "renderer"); whether or not this language binding will look like PHIGS or not is still up to debate. Considering that the PEX protocol itself is based on PHIGS, my guess is that the immediate-mode interface (when and if it becomes available) will have lots of PHIGSisms except when it comes to managing hierarchy and display control. -- Rich Disclaimer: I work for Evans & Sutherland, which makes a PEX box, but I don't represent them in any official manner. Rich Thomson thomson@cs.utah.edu {bellcore,hplabs,uunet}!utah-cs!thomson ``If everybody is thinking the same thing, is anybody thinking?'' --Bob Johnson
shrum@hpfcdq.HP.COM (Ken Shrum) (10/02/90)
HP's PHIGS PLUS product provides "full subsystem performance" - it
renders as fast as the hardware can.
Ken Shrum
Graphics Technology Division
HPmherman@alias.UUCP (Michael Herman) (10/03/90)
I think another increasingly important issue will be whether the display surface and display generation hardware are local to the host machine or remote (networked) to it. In some cases, these will be separable issues.
thomson@cs.utah.edu (Rich Thomson) (10/03/90)
In article <390050@hpfcdq.HP.COM> shrum@hpfcdq.HP.COM (Ken Shrum) writes: >HP's PHIGS PLUS product provides "full subsystem performance" - it >renders as fast as the hardware can. I can't resist-- E&S' ESV renders PEX (i.e. PHIGS/PHIGS+) as fast as the hardware can. ;-} Actually at SIGGRAPH, HP's booth (which I think had 18,000 watt speakers ;-) was right next to ours and they were touting their product as having the fastest X and the fastest PHIGS in X (not the same thing as PEX, BTW). Some people came up and asked me what I thought about this, seing as I was a lowly luggage-tag maker at the booth. I told them to go ``kick the tires'' on each machine and decide for themselves which one was the fastest. After seeing their machine perform in some demos run by their salesman, I wasn't too concerned about saying that. -- Rich Rich Thomson thomson@cs.utah.edu {bellcore,hplabs,uunet}!utah-cs!thomson ``If everybody is thinking the same thing, is anybody thinking?'' --Bob Johnson
leech@cezanne.cs.unc.edu (Jonathan Leech) (10/03/90)
In article <1990Oct2.173140.7728@alias.uucp>, mherman@alias.UUCP (Michael Herman) writes: |>I think another increasingly important issue will be whether the display |>surface and display generation hardware are local to the host machine or |>remote (networked) to it. In some cases, these will be separable issues. Definitely. The Pixel-Planes 5 graphics multicomputer developed here is currently running off a Sun-4 over VME. The non-VonNeumann bottleneck thus created severely limits what we can do. It should help a lot when we move to a DEC host with TURBOchannel.