Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!rice!hsdndev!husc6!genrad!stardent!jch From: jch@Stardent.COM (Jan Hardenbergh) Newsgroups: comp.graphics Subject: Re: Practical Intro to PHIGS (new book) Summary: Plenty of room for more detailed books, this is still great Message-ID: <1991Apr25.034649.3579@Stardent.COM> Date: 25 Apr 91 03:46:49 GMT References: <1991Apr16.022646.6268@Stardent.COM> <24283@well.sf.ca.us> Organization: Stardent Computer, Concord MA Lines: 158 levine@well.sf.ca.us (Ron Levine) writes: > In two previous postings on this topic, I averred that the most > useful display update deferral mode in PHIGS is WAIT, or at > least that ASAP is the least useful deferral mode. Let me here > make clearer the basis for this assertion. > > Here are the relevant facts: Still it should be noted that WAIT/UQUM will great for wireframe editing of models. That is not the whole constituency of PHIGS. > Now the Howard et al book does not give the slightest clue as to > these important practical considerations. This statement is just plain not true. The book does about as well at explaining them as the spec (PHIGS88/PHIGS89) does. That is not a full discussion on when to use which ones. More on this later. I did not give complete info before (missed the publisher) and have received some inquiries, let me give the complete info. A Practical Introduction to PHIGS and PHIGS PLUS TLJ Howard, WT Hewitt, RJ Hubbold, KM Wyrwas Addison-Wesley 1991 ISBN 0-201-41641-7 Price 24 Pounds (that's all I got :-) > On the contrary, it > proceeds on the unstated assumption that the default deferral > mode is ASAP, usually a bad choice (although the default in some > implementations). As I mentioned, it contains many important > unqualified statements which are false in those implementations > using WAIT for the default, and almost none of its example > programs would produce the expected picture in such > implementations. Yes, this was a mistake on the authors part. And, yes, I believe that the examples will not run with out a call to update workstation added. However, I haven't finished typing in the SEVEN page viewing example or the EIGHTEEN page PHIGS-PLUS example showing how to use lighting and shading (well, only flat shading in the example, but astute readers can figure out how to change the argument to psetintshadmethod()). The examples alone make this book great. > Now here is a question about PHIGS deferral mode for which I > don't have an answer. What possible use could there be for > deferral mode ASTI (At Some Time)? The standard spec seems to > imply that this deferral mode allows implicit regeneration to > occur, but at completely undetermined times. The standard also > allows an implementation to make ASTI equivalent to ASAP, which > indeed seems to be the case in the implementation with which I am > most familiar (although you couldn't tell it from their > documentation). I cannot imagine that an application programmer > would be indifferent as to if and when implicit regeneration > might occur. Can any of the Phounding Phathers of PHIGS tell me > what they had in mind when they created this deferral mode? I am a long ways from a "PHIGS Architect", as Eileen refers to herself, but I was at the Palm Bay meeting in 1985 when that stuff got laid out. I think the rational was that some devices would suffer severe performance penalties if they had to buffer everything up. It was not lobbied for strongly by anyone, but rather thought to be a good middle ground between ASAP and WAIT. I also remember it being quite a hot issue and when the total deferral/modifiaction package was put together - solving the main needs of those who cared about UQUM, BNIL, etc everyone was quite relieved to have a solution. I do agree with you that there are too many options. I question the usefulness of BNIL and BNIG, anyone ever used them? Theoretically, they seem nice, but that implies alot of correct cooperation between PHIGS input and output. Of course, I always question the usefulness of PHIGS input in the light of "modern UIs", but that's another story. I can only see the usefulness of three of them. WAIT/NIVE as useful for applications that want display a frame at time. WAIT/UQUM is useful for editing wireframe geometry. UQUM in Z buffer is still a research issue to my knowledge. ASAP is useful for debugging your PHIGS application. The same way calling XSynchonize to force flushes is useful. Deferral and Modification modes are not the penultimate to understanding PHIGS. They are important to developing a tuned application, granted. So are things like how many structures you use and how big they are, how you navigate in structures, the edit mode you use, where in the structure you edit ( at the end? ). And, ASAP should probably be the default - let those that know better change it. We knew when we changed it back at Apollo that niave users would have to learn another thing - but a large customer said jump... PHIGS is suffering because there is a tremendous leap in comprehension one needs to make before one feels comfortable with it. This book has exactly the right approach help people make that leap. The example they give on page 18 of the simple PHIGS program that actaully draw something is great. That is exactly the answer to the graPHIGS question last week. Considering the state of many who want to know about PHIGS is "Give me any example program that draws anything", I'd say the Practical Intro book is better than great. It is unfortunate that the examples will not work out of the box on all PHIGSs - but if they did it would be #ifdef CITY! No two PHIGSs are alike in thier arguments to popen_ws. I hope the wide spread adoption of the PEX-SI PHIGS C binding & API help fix that. (and by the way the PEX-SI does have ASAP as the default). Ron Levine states in another article that he does have a tutorial that is being considered for publication. Hopefully, that does not affect his objectivity more than being listed in the acknowledgements affects mine. Obviously, Ron has lots of insights that are not in the Practical Intro book. Do those insights make this book any less useful to those who cannot cite chapter and verse out of the spec? No. This book is good for anyone who is using PHIGS now. If you can wait, you might hope that one of the two other books scheduled to be out at SIGGRAPH will be better. (Prentice Hall (Valerie Clark) and Wiley & Sons (Hopgood & Duce) They might be. Or you might want to wait longer. Ron suspects "a truly valid and helpful book on PHIGS PLUS is still about a year away." But the Practical Intro book sets a pretty high standard. I'm currently negotiating the movie rights for my script of "The Battle of the PHIGS Books" - with complete comparisons :-) The first crop of books will contain information on how to use the various pieces of PHIGS. It's a fair amount like the Oliver Jones Intro to X book. Tells you enough to get something going, but not enough to overwhelm you. I think there is great value in that. If Ron Levine can put all of his insights into a book aimed at someone who is familiar with PHIGS but wants to design an application to maximize the performance of PHIGS for thier applications MORE POWER to him. I'd love to see a book about that, but to me that is second generation knowledge. There are a zillion things that can affect PHIGS and PHIGS implementors optimize certain paths for thier favorite customers - things leave the intuitive. For example, 3D lines are faster than 2D lines, Gouraud shaded polygons are fast than hollow polygons - that is true on at least one PHIGS library on at least one machine. Heck, a good discussion of the optimum structure size vs. the cost of instancing would be worth a paper. The bottom line for me is that the Practical Intro book has great examples, great diagrams and for most things great descriptions. It's not perfect - I did not say it was. Of course the really interesting PHIGS issues are the things that are missing form the spec all together. Immediate mode springs to mind. PHIGS really needs immediate mode - write your congressman this week or next if you think immediate mode should be added to PHIGS. It's a little late to add it to PHIGS88 or PHIGS-PLUS but if everyone agreed on how to do it that would be a BIG first step. Of course there are other things like texture mapping, transparency and antialaising, too. -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742