jch@Stardent.COM (Jan Hardenbergh @stardent) (08/30/90)
Once upon a time, PHIGS had "non-retained structures" which meant that the application could insert elements into a write only structure and the PHIGS implementation would display them and then forget them. However, defining precise behavior accross storage tubes, vector refresh tubes and these new gizmos called raster displays was hard. For example, in a vector refresh tube did it last until the next update workstation, or until the next implicit regeneration? 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? What's the right thing to do? Create yet another graphics standard, no. Hopefully, I do not have to argue this. Use something else for immediate mode, no - these applications are mostly happy with the primitives, viewing, lighting/shading and geometry pipeline of PHIGS. So, that leaves adding immediate mode to PHIGS. This is technically pretty easy - just bypass structure storage. The hard part is getting the right conceptual framework. 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 ). Note, that DEC-PHIGS has immediate mode based on a PEX renderer and Template's Figaro still has non-retained structures. The graPHIGS documents give no hint of it. Anyone willing to get down and dirty with the PEX protocol can have immediate mode. 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. 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. 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? 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. 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. How does immediate mode graphics interact with input echo areas? Answer: remove input from PHIGS. If anyone has any experience with immediate mode PHIGS, or related graphics systems or if you just have some opinions please email them to me. I'll post a summary in early September. Note Bene! Especially you PHIGS purists. These opinions and ideas are my own. While they may someday be of interest to someone, currently I am acting one my own behalf and not one anyone or anything else's behalf. -- -Jan "YON" Hardenbergh - jch@stardent.com uunet!stardent!jch Stardent Computer, Inc., 95 Wells Ave., Newton, MA 02159 (617)964-6228x261