Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!well!levine
From: levine@well.sf.ca.us (Ron Levine)
Newsgroups: comp.graphics
Subject: Re: Practical Intro to PHIGS (new book)
Summary: More on deferral mode
Message-ID: <24396@well.sf.ca.us>
Date: 24 Apr 91 01:26:07 GMT
References: <1991Apr19.175910.2922@Stardent.COM> <24373@well.sf.ca.us>
Lines: 75



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:
 
1. In general, in order to be sure that the displayed picture is 
the correct rendering of the picture defined by the current state 
of the PHIGS data bases, including the centralized structure 
store and the workstation state list, it requires regeneration, 
i.e. traversal of all the posted structures, respecting their 
relative display priorities, the order of primitives within the 
structures, and whatever hidden line/hidden surface methods may 
be in effect.

2. Depending on the complexity of the picture and the rendering 
speed of the workstation, regeneration may well require a non-
negligible amount of time, perhaps a long time in relation to 
what is needed for good interactive response.  Even on the 
fastest workstations, applications will tend to want to push 
picture complexity to the practical limit. 

3. Generally, an single iterative change in the picture which the 
application wishes to present to the user will involve a number 
of calls to PHIGS functions which modify structure contents 
and/or workstation state, i.e. the data which define the correct 
picture--sometimes only a few such calls, sometimes a large 
number. 
                                                      
4.  If the deferral mode is ASAP, then every individual function 
call changing workstation state will implicitly cause a 
regeneration, and every individual function call changing the 
contents of a posted structure will implicitly cause a 
regeneration.  This is certainly undesirable under facts 2 and 3.  
Part of the problem could be avoided by unposting a structure 
before editing and reposting after editing, but if there were 
several posted structures needing editing (generally true), then 
there still would be several needless unwanted regenerations.  A 
better solution is to use deferral mode WAIT.

5.  If the deferral mode is WAIT, then there is no regeneration 
until the application explicitly calls for it, after having made 
an entire batch of incremental changes to the data base.  The 
application, not PHIGS, is in control of the costly regeneration 
process.  Clearly the best solution under the stated facts.

Now the Howard et al book does not give the slightest clue as to 
these important practical considerations.   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. 

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? 

        Ron Levine
        Dorian Research, Inc.
        (415)-535-1350