Re: Moving objects and incremental redisplay

• To: ncramer@BBN.COM, SWM@stony-brook.scrc.symbolics.com
• Subject: Re: Moving objects and incremental redisplay
• From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
• Date: Tue, 28 Sep 1993 15:47 -0400
• Cc: bha@ata.ca.boeing.com, clim@BBN.COM
• In-Reply-To: The message of 28 Sep 1993 14:32 EDT from Nichael Cramer <ncramer@BBN.COM>

    Date: Tue, 28 Sep 1993 14:32 EDT
    From:     Nichael Cramer <ncramer@BBN.COM>

    Scott McKay <SWM@stony-brook.scrc.symbolics.com> writes:

	Date: Tue, 28 Sep 1993 12:42 EDT
	From: Brian Anderson 234-0878 <bha@ata.ca.boeing.com>

	CLIM 2.0beta2
	ACL 4.2beta2
	Sparc
	[... Query about moving output records ...]

    >For example, in order to move an object you simply:
    >
    > 1) compute the region of the object
    > 2) move the object to its new position
    > 3) replay the output records overlapping the objects old region
    > 4) replay the output records overlapping the new region

    A heads-up:

    There seems to a problem in the CLIM if you move presentations around (this
    certainly true in ACL-CLIM, don't know about the others).  Specifically the
    standard, default output-history gets confused (this is particularly a
    problem when presentations overlap and/or are at the same vertical
    position).

    It seems to help replace the output history in your window with something
    like the following:

       :OUTPUT-RECORD (MAKE-INSTANCE 'CLIM::R-TREE-OUTPUT-HISTORY)

Yeah, the coordinate sorted set output history is pretty un-robust.  I
wonder if it should no longer be the default.  But I didn't really trust
my implementation of R-trees (it's *very* hairy), and did not dare to
make it the default.

• Prev: Re: Moving objects and incremental redisplay
• Next: Re: Moving objects and incremental redisplay
• Index: CLIM Mailing list (1-Jan-93 to 31-May-94)
• Thread: CLIM Mailing list Index (1-Jan-93 to 31-May-94)