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

Re: updating-output CLIM 2.0

  Date: Thu, 27 Aug 92 13:30:37 EDT
  From: "Ben A. Hyde" <gensym!bhyde@harvard.harvard.edu>
  
    I'm reading the CLIM Release 2.0 Specification, May 6, 92.  While I'm not
  a CLIM user, I've built a huge amount of UI over the years and I'm finding
  it very interesting.  Lots of questions come to mind, but let me start with
  one.
    Updating-output is very like a construct I've used in other programs, i.e.
  you write a routine that displays your output.  Then you discover that you
  want that same routine to do other things, like update the screen when the
  underlying document changes.  The operations enabled by having a path of 
  unique-ids, and a cached-value (aka update tick) are also a UI trick I've 
  seen in many programs.
    It is hard to tell in CLIM what features are excess junk piled on to
  please the ivory tower, and verses the stuff added to clarify
  the performance and interface.  For example I'm am not surprized 
  that designs are a superclass of regions.  This more of a problem for
  people who haven't actually built a complex UI.
    In anycase, my question.  Is it necessary to entangle the rich output
  records with the concept of updating-output.  In system's I've built it
  is cheap to generate the output.  That building, maintaining, walking,
  etc. any backing store is expensive and slow.  In system's I've built the
  concept of updating output use the screen bits as it's only output cache.
    I'm having trouble developing an affection for CLIM's rich backing store.
  Most programs I've been involved in do not maintain an output cache (other 
  that the screen bits), and I'm having trouble seeing that it is necessary.  
  Couldn't the routine captured by updating-output provide all the services 
  that the output record is?  I've always it asked to.
    - ben hyde, Gensym Inc. Cambridge

Output recording can be turned off if you don't think you need it.  In that
case, I have found that you get nearly the same performance as the underlying
window system.

The default kind of output recording is indeed expensive, but unless you
exceed hundreds of output records, the expense is not noticeable.  I believe
that if someone profiled its performance, the main expense would be in
calling MAKE-INSTANCE for each output record (and later collecting all
of the instances as garbage).  Once constructed, however, replaying the output
history should be at least as fast as generating output with output recording
disabled.

In my experience, displays that exceed hundreds of output records tend to
be displaying a structure for which there is a corresponding data structure
maintained by the programmer.  In that case, it is possible to specialize
clim's output-recording protocol to use the programmer's data structure
to represend both itself and the output history of the window.  For example,
drawing a graph of 100,000 individually mouse-sensitive data points
is important to me.  With some help (from SWM) I was able to construct the
graph data once and then hand it to the window saying "here is your output history".
Replaying the data was as fast as generating the output with output recording disabled,
but this way each data point is a presentation.

[In the next round of CLIM documentation, it would be nice to see an example
of something like this!]

I'm not sure the jury is in on updating-output.  You need it most when the
display is NOT CHEAP to generate.  Suppose for my 100,000 point graph I want
to change the units from "Fortnights" to "Furlongs".  Walking the output
history is not expensive as long as there is a caching-point that encapsulates
the entire 100,000 points of data, so that clim doesn't have to inspect each point.

Although updating-output works OK for relatively simple displays, when you
don't really need it, I have had terrible luck with complicated displays.
In my opinion it is too slow and too buggy.  Nevertheless, I find myself using
it (though not for graphs).  In defense of the implementors, it is a hard thing
to do for the general case.  

I think everyone feels that there is "excess junk" in clim, but nobody seems
to agree about which parts are the junk.  Each feature makes some constituency
happy.  If the specification is not going to get smaller, then I would like
to see CLIM broken into libraries.  For example, all those color symbols
(+white+ etc) should probably be put into a file that can be loaded if
you need it, but if you don't need it your lisp image will be that much
smaller.

jeff morrill
Follow-Ups: References:
Main Index | Thread Index