Date: Thu, 11 Apr 91 11:33:11 -0700
From: chapman@lll-crg.llnl.gov (Carol Chapman)
Message-Id: <9104111833.AA14880@lll-crg.llnl.gov>
To: bug-at@ATHENA.MIT.EDU
Subject: redundancy in Plotter.c's Resize function

In the Resize callback in Plotter.c, AtPlotterLayout is called,
followed by calls to ResizeLegend and RESIZECHILD.  These last 2 calls
appear to be redundant because AtPlotterLayout also calls them.  I
commented out the redundant calls with no observable bad effects.

carol chapman
Received: by ATHENA-PO-3.MIT.EDU (5.45/4.7) id AA17258; Sun, 21 Apr 91 11:31:26 EST
Received: from munnari.OZ.AU by ATHENA.MIT.EDU with SMTP
	id AA07390; Sun, 21 Apr 91 12:31:07 EDT
Received: from melba.bby.oz (via ditmela) by munnari.oz.au with SunIII (5.64+1.3.1+0.50)
	id AA28384; Mon, 22 Apr 1991 02:31:00 +1000 (from gnb%bby.oz.au@melba.bby.oz.au)
Received: from baby.bby.oz.au by melba.bby.oz.au (4.0/SMI-4.0/BBY)
	id AA16985; Tue, 16 Apr 91 17:16:05 EST
       (from gnb@bby.oz.au for bug-at%athena.mit.edu@munnari.oz)
Received: by baby.bby.oz.au (4.1/SMI-4.1)
	id AA10747; Tue, 16 Apr 91 17:16:01 EST
Message-Id: <9104160716.AA10747@baby.bby.oz.au>
To: bug-at@ATHENA.MIT.EDU
Subject: Some thoughts on the redisplay sequence
Date: Tue, 16 Apr 91 17:15:57 +1000
From: Gregory Bond <gnb@bby.oz.au>

Guys,

I have been having some serious thinkies about the redisplay and
redraw policies of the plotter widget.

It seems that the policy decisions of what to redraw and when is
diffused throughout the Plotter and Axis widgets.  I cannot yet fully
understand what the sequence of redrawing is....

One side effect is that far more redraws than necessary are happening.
E.g. in a callback routine, try changing a couple of things, such as
the color of two different plots, then changing an axis.  The whole
graph redraws three times.  This is very annoying!

What we need is some agreed protocol for child objects to ask the
parent widget for a redisplay, and some way for the parent to collect
up all the pending requests and fulfil the most stringent one, once,
just before going back to the XtMainLoop.

I have listed the various severity levels of redraw I have identified
below:

1) Redisplay.  An expose event for a region (or collection of regions)
   was received and needs to be redisplayed.  These are handled by the
   parent (as objects have no redraw procedure!)

2) Refresh. The colors/line styles etc have changed, and a redisplay
   needs to be done.  Could possibly be broken into 2 parts - a
   refresh that requires a complete clear (e.g. background changed) or
   one that can be achieved by just redrawing the existing child
   object (e.g. color changed) No computing, scaling, layout, looking
   at the data is required.  Can come from any child or the parent.

3) Layout.  Something in the pixel geometry has changed, either the
   widget changed size, or something like title or legend was added or
   removed that requires re-layingout the inner proportions of the
   widget.  Will force a complete redraw.  Can come from the parent or
   the axis objects, but not from plot objects (unless you count plot
   object legend constraint resources, which are handled by the
   parent).

4) Plot bounding box changed.  The data for a plot object has changed
   and the bounding box for that object has changed.  This is passed
   up to the parent from plot objects only.  The parent, which uses
   the union of all child bounding boxes, may decide no change is
   needed in the overall boundingbox and just treat this as a refresh,
   or if necessary force a rescale.

5) Rescale.  Some of the data has changed, and a new bounding box is
   required.  The new bounding box is computed, new axis scales
   chosen, and a complete redraw is done.

I think it is important to separate the two main redisplay problems:
the boundingbox has changed, and the pixel geometry has changed.  This
avoids having to so more work than is necessary, and adds a lot of
flexability in the interface with applications.


As for the mechanism, I have two possibilities.

The first is Work functions.  These are called when the main loop is
waiting for input, so you can be sure all events, action procs,
callbacks etc that might affect the graph in the near future have
happened.  During the Setvalues etc you set up flags and register a
work proc, which does the required redraw then deletes itself when
there is time. (See Xt C Language manual, sec 7.8).

The second is to use the return value from the SetValues function.
This is somewhat used at present, but there are also raw calls to the
Redraw routine in various places, and I am not sure at what point in
the processing of events the redraw routine is called after a
SetValues returns True.


What would be most interesting is a couple of callback lists, one
associated with the rescale and one associated with the re-layout.
These would be called after the "default" stuff had been calculated,
but before it was acted on, so that they could change the default
choices. This would allow applications to do clever things with
multiple graphs (e.g. make sure they all have the same X axis scale
and position, and thus line up vertically on each other).

I have not much experience with the internals of widget redisplay, so
can anyone enlighten me on this????

Can anyone elucidate the current redraw policies and operation?

Am I completely out to lunch?

Greg.
-- 
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au    non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb