jch@Stardent.COM (Jan Hardenbergh @stardent) (10/06/90)
All this talk of immediate mode reminded me that I got a few responses from my posting about immediate mode in PHIGS. I have enclosed them here. One is from Tom Gross, noted PHIGS lecturer and professor and the other from Miente Bakker at CWI where they contribute much to graphics standards. One of the reasons for asking was to explore the migration path for the Stardent XFDI X11 extension for 3D graphics. At this point it seems there are too many ramifications to trying to fit immediate mode cleanly into PHIGS proper. As far as the current immediate mode vs display list debate goes I think Rich Thomson at E&S has been doing a good job of exploring issues ( when he's not on one of his sales pitches ). > 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. Yes, I got lots of mail from the PEX community expressing interest and hope to get some discussion going soon. ============================== responses to earlier posting ========== Date: Fri, 31 Aug 90 18:14:27 EDT From: Tom Gross <uunet!RELAY.CS.NET!tgross%bingo.prime.com> Subject: non-retained graphics >Today, PHIGS ( PHIGS88 + PHIGS-PLUS ) has definitely found a lot of >support, but it is clear that some applications need immediate mode. >Here are some of the reasons: > > a - Change data too often to make display list worth while. > b - Don't want duplicate geometry data. > c - Too much data to put in display list. > d - Dislike posting/permanance. > e - others? e: An application may want to maintain its own display list rather than use PHIGS which (probably) has to push all kinds of state to traverse "execute structure" most of which the application knows it won't be using in the executed structure. >Why will it be any easier to add immediate mode to PHIGS than it was >in the early 1980s? ANSWER: only define behavior for raster frame >buffer. ( Actually, any display system which has memory that can be >overwritten works ). I'm not sure I buy your argument that non-retained structures were dropped because of the ill-defined behaviour for stroke devices. What does the PHIGS issues log say about this? The reasons for dropping non-retained structures were undoubtedly documented. QUM doesn't mean much for metafile-out but dynamic modification entries in the workstation state cover that pretty well (everything being IRG in that case). It may be that immediate mode was dropped because no one could agree on how to define it. My point is that it would strengthen your argument if you documented the history of the issue. Also, if it's so easy to define for raster devices why isn't it obvious which method you propose is the best? >Here are some of the methods used for immediate mode in PHIGS and other >graphics systems. > >1 - non-retained structure ( PHIGS pre-1985, Figaro ) > > The application make a call for each "element" and it appears > ASAP on the screen. No real structures are used but in the > PHIGS statelist a structure is open ( PHOP,*,STOP,* ). It > fits cleanly into the PHIGS concepts. How do the non-retained graphics fit with the retained graphics already on the screen? Do they at all? If yes, is the SVR correct or simulated or something new? Do the non-retained graphics get z-buffered with retained graphics? Or just drawn on top? If you can't put non-retained graphics on the same workstation as retained graphics, how exactly do you prevent this? Are you suggesting that maybe non-retained graphics workstations be a separate workstation type? These are just some issues that come to mind immediately. Don't forget if you're going to standardize something it would be nice if people knew what standard behaviour is >2 - Fire and forget posting ( post and forget ) ( Application dream ) > > Structure editing is as usual but posting is transient. You > post a structure, the graphics are there until a screen clear. > Fits cleanly into PHIGS concepts. Set display update state to WAIT/NIVE Post the structure Update workstation Unpost the structure Whose "application dream" is this? I think PHIGS supports this very nicely. [jch - not true. unposting and updating gets rid of previous image. ] >3 - Begin/End Render ( DEC-PHIGS, PEX protocol - NOT API!, yet ) > > The application make a call for each "element" and when the > end renderer happens the picture is gauranteed to look correct. > Don't know how it fits into PHIGS concepts. Is it PHIGS state > or Workstation state, Anyone? Are you asking if in DEC-PHIGS it is PHIGS state or Workstation State? Same questions as with case number 1, I think. >4 - Packet Mode ( Apollo GMR3D ) > > Application is privy to the ( some ) graphics instruction > formats and builds its own "packet" of graphics data. > it then "displays" this data in a view, I think. > Conceptually similar to post and forget but application > controls display list memory. Same questions as with case number 1, I think. >5 - Selective Traversal ( refresh structure/element range ) > > Similar to post and forget but application gets to further > specify which elements in a structure should be refreshed. > Great for do it your self UQUM. Structures must be posted. > Fits cleanly into PHIGS model. Why was conditional traversal not in PHIGS (and then removed from PHIGS-PLUS when it went to ISO)? This would be nice to have. It would also be nice to have selective traversal for picking, i.e. when the application knows it only wants to traverse a particular view for a pick. Also would make selective regeneration of views possible. Very useful, but doesn't in itself remove the requirement of maintaing PHIGS CSS. >How does immediate mode graphics interact with input echo areas? >Answer: remove input from PHIGS. NOW you tell us! Sheesh... -Tom Gross Prime/CV tgross@cvbnet.prime.com Date: Mon, 3 Sep 90 16:49:14 +0200 Message-Id: <9009031449.AA10019@ekster.cwi.nl> To: jch@Stardent.COM Subject: Re: Immediate mode in PHIGS. Organization: CWI, Amsterdam Cc: miente@cwi.nl What about GKS-3D? It is an Int. Standard, albeit not an ANSI standard. It does support the IMMEDIATE mode (output outside segments). There are even stable bindings (C and Fortran) and implementations (at DEC, e.g.). It has only a few flaws: 1) it is ignored within the US; 2) there are no PHIGS+like extensions. -- _________________________________________ | | | Miente Bakker | | CWI | | Kruislaan 413 | | 1098 SJ Amsterdam | | Netherlands | | | | phone: +31-20-592-4122 | | fax: +31-20-592-4199 | | email: miente@cwi.nl | | | |_______________________________________| -- -Jan "YON" Hardenbergh - jch@stardent.com uunet!stardent!jch Stardent Computer, Inc., 95 Wells Ave., Newton, MA 02159 (617)964-6228x261