CLIM mail archive
[Prev][Next][Index][Thread]

Drawing Order

    Date: Tue, 8 Dec 1992 19:39 EST
    From: Bill York <york%oakland-hills@lucid.com>

       From: Erik Eilerts <eilerts@cs.utexas.edu>
       Date: Tue, 8 Dec 1992 17:30:46 -0600
       X-Mailer: Mail User's Shell (7.2.3 5/22/91)

	     System:  Lucid 4.0, Clim 1.1, Ultrix, X11R5

	     I'm drawing a graph in an application window with scroll bars, but 
       it is having a problem.  The appearance of the graph depends on the order
       in which the elements of the graph are drawn.  But, CLIM seems to be 
       reordering the way the objects are drawn when the window get's refreshed
       or scrolled.
	     For example, I want the following:

	     ------------ object1 -------------

	     This is a:
	  1.  a line segment
	  2.  a filled rectangle who's ink is the background
	  3.  the word object1

	     The end result is that the filled rectangle blanks out part of the
       line segment so that the word can be drawn with some whitespace around it.
       But, when I scroll my window, this drawing order seems to change randomly. 
       So, I like to know if there's any way to gurarantee the order that objects
       get drawn when a window is scrolled?
	     If this is too hard, I'll just compute the intersection points of the
       line segment with the word.

If you (Eilerts) can send me a small function that outputs failing case
of a line segment, a filled rectangle, and a text string, I can take a
look at this to see if anything is going wrong that we don't already
know about.

    CLIM sorts output records in Y-coordinate order so that the output
    history can be searched more efficiently for mouse sensitivity
    computations.  There is supposed to be code that makes sure that
    overlapping presentations get replayed in the order in which they are
    drawn, but it has been known to have bugs.

As Bill says, coordinate sorted sets are supposed to replay overlapping
presentations in the correct order (and so far as I know, this actually
does work correctly).  The replay order of output records that do not
overlap is undefined, but that should not ever matter, except if you are
doing animations (in which case, none of CLIM's output records is
adequate).

    You can flush the coordinate-sorting entirely by installing a stupider
    kind of output record as the top-level history record for your window:

    (setf (output-recording-stream-output-record win)
	  (make-instance 'clim::linear-output-record))


0,,
References:
Main Index | Thread Index