beginners question about incremental redisplay

[MILLER@vax.cam.nist.gov (Bruce R. Miller)]

Date: Wed, 21 Mar 90 13:53 EST
To: sauthier%elma.epfl.ch%CUNYVM.CUNY.EDU@vax.cam.nist.gov, slug%AI.SRI.COM@vax.cam.nist.gov
In-Reply-To: <900321175613.22c0fe66@SIC.Epfl.CH>
Message-ID: <19900321185315.1.MILLER@ARTEMIS.cam.nist.gov>
Character-Type-Mappings: (1 0 (NIL 0) (:SWISS :ITALIC NIL) "HL12I")
                         (2 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB")
                         (3 0 (NIL 0) (:SWISS :ROMAN :SMALLER) "HL10")
Fonts: CPTFONT, HL12I, CPTFONTCB, HL10

    Date: Wed, 21-Mar-90 13:22:37-EST
    Date: Wed, 21 Mar 90 17:56:13 N

    I tried to use the incremental redisplay capabilities of genera (7.2)
    without success. I want to have a program able to handle some graphical
    output. Each piece of graphic is also intended to be selectable and therefore
    corresponds to a presentation type. I also want to be able to interactively
    move this pieces on the screen.
    I tried to implement this after an example found in the genera documentation
    and the result was not exactly what I expected. For example if I select a
    piece of the "drawing" and I move it, it is the only things which is redrawn,
    but under certain circumstances (unfortunately, I don't know what they are,
    but I suppose they have something to do with the overlapping of the highlighting
    boxes) other part of my output are disturbed or shifted (the highlighting of
    the presentation does not overlap the presentation anymore).

    Before going into details, I would know if it is possible to do this, if
    someone has had the same troubles, or if I am doing something wrong.

I, too, thought that presentations and generic graphics would be a great
mix!  And, with some  caveats, it is.    The short answer  to your three
questions are (most likely): YES.  

A slightly longer answer is that the combination of 1) the system  being
very non-trivial to design & implement, 2) having a few bugs in design &
implementation and 3) the not-so-obvious way of using it sometimes being
the best way make the thing difficult to get right for non-trivial uses.

    thanks for help.

	Eric Sauthier
	AI lab, Swiss Federal Institute of Technology, Lausanne

	EMAIL : sauthier@elma.epfl.ch

I developed a graphics program which presents graphical images which you
can modify by clicking & so forth.  It kind of evolved into a working
program and I can't give definitive answers to what is right & wrong,
but I'll mention some things that I can remember, or notice by browsing
my code.

Basicly there were two kinds of presentation relationships that created
problems `ON-TOP' and `WITHIN':

1) There is  a replacing-presentation  function which  wasn't much good;
the refreshing of overlapping presentations was inconsistent.  I had  to
erase it and re-present it.   A further caveat here is that if you  want
to preserve the Z order of the presentations (ie who is `on top of' who)
then you've got to erase all the  ones on top and represent them  in the
correct order. (I think replacing-presentation suffered here as well).

2) Doing anything to an inferior presentation; a graphic presented
within another graphic which has its own presentation never worked.
The superiors apparently remember where the inferiors are and there
seems to be no way (w/o sources) to patch them up.
I had to find the root superior and erase/redraw it.

None of my comments should be taken as absolute truth; I just found 
ways that seemed to work consistently.  The more obvious ways to do
things worked inconsistently, but maybe I overlooked something.

A typical code fragment is 
;;; 1Well, this one finally works !!! I dont know why the particular options are required.
0(defun 2erase-presentation 0(presentation)
  (graphics:erase-graphics-presentation presentation :stream *plotter*
					:redisplay-overlapping-presentations t
					:delete-too t
					:clear-inferiors nil ; 3T
0					:enable-recording T))
[To the comment should be added `or IF they are!!']

Take heart though; It CAN be made to work.  
(I wonder how things would/will be with CLIM?)

Bruce
miller@cam.nist.gov