CLIM mail archive

[Prev][Next][Index][Thread]

Re: Moving objects and incremental redisplay



    Date: Thu, 30 Sep 1993 10:48 EDT
    From: Steve Mundy <samundy@mmm.com>

    >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

    Does #3 imply that a user needs to record overlapped objects
    in order to to replay those records after objects are moved?  If so,
    then what is the purpose of incremental redisplay?  Automatic replay
    should be part of the fundamental clim spec; clim should know what
    objects are overlapped and  need to be replayed without explicitly having to
    relay that information back to clim.  I sure hope that I am
    misunderstanding the implications of step #3.

I don't really see what is so hard about the following:

  (let ((old-region (clim:bounding-rectangle object)))
    (clim:bounding-rectangle-set-position object new-x new-y)
    (clim:stream-replay stream old-region)
    (clim:stream-replay stream object))

I disagree that "automatic replay should be part" of the core of CLIM,
given that doing it yourself is so simple.  If we did that, facilities
that did "batched" moving of records would have to explicitly inhibit
this or else suffer from terrible performance which people would then
incorrectly attribute to CLIM "just being slow".

If you want to write a "move-and-replay" function, it's pretty simple.

    Tracking which objects are overlapped is not a viable solution for our
    application due to the number of overlapped regions, and clim's speed
    (or lack thereof, even on a sparc 10).  If we have to track all of
    this ourselves, we may as well write everything in C++ to get the execution
    speed we need.

Um, hold on, wait a minute.  Either you have to track overlapping
regions or CLIM has to do it for you, right?  CLIM is not magic -- it
has to do work to do this.  For some applications, you the programmer
know some things about your application that CLIM does not know, and
that knowledge can enable you to do the job better than CLIM can.

If CLIM were written in C++, Forth, or Cobol, either your program or
CLIM would *still* have to do this work.  There is no escaping this.

If you are seriously considering recoding your application in C++ "for
speed", you are guaranteed to have to do all this work yourself.  If
that is the case, you might try doing the same thing in Lisp to see how
much effort you have to spend.

    I would appreciate any clarification of this part of the clim
    protocol.  We have had a lot of problems with overlapped regions, and
    have had to hack our code to avoid overlapping altogether.  We are
    running ACL 4.2.beta.0 and CLIM 2.0.beta.2.


References:

Main Index | Thread Index