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

CLIM philosophy wrt to X.

    Date: Wed, 4 Sep 1991 02:57 EDT
    From: chee@isi.edu

    Sorry for the delay in the follow-up, I just returned from a vacation.
    Anyway, I think the discussion so far has for the most part missed the
    gist of my query, so I'll restate them.

    My concerned is not so much with the addition of new functions/macros,
    not yet anyway, rather it is with the higher level decisions about
    what CLIM should expect, say and do in different windowing
    environments, and how that impact the CLIM user if any.  (Anybody have
    stats on the platforms CLIM is on, especially lispm vs
    rest-of-the-world?  It seems that Symbolics is still driving the
    development & decision process, which is good for the most part (I
    would prefer to still be working on a Symbolics, but, that battle has
    long been lost), but there doesn't seem to be enough consideration yet
    about other Lisp environments, which prolly is because CLIM is still
    young, but still... My suspicion is that if CLIM is to catch on, the
    rest-of-the-world portion has to grow fast, hence their environment be
    taken more seriously)

Symbolics is certainly not driving the development and decision process.
We are actively contributing in important ways, but no more so than ILA.
And Franz will play a large role in the development of CLIM 2.0 for Motif
platforms.

As for statistics, CLIM 1.0 has roughly equivalent run-time performance
on an XL400 running Genera (on Genera's native window system), on a 30MHz
486 running CLOE and MicroSoft Windows, and on a Sparcstation 1 (that's
one, not one-plus or two) running Franz Allegro or Lucid.  I believe that
the performance on MCL 2.0 on a Mac IIfx is also comparable.  By
comparable, I mean that the XL400 wins some of the benchmarks, CLOE wins
some, Allegro wins some, and Lucid wins some.  No single platform does
markedly worse than any other in their poorest benchmarks.

As a Symbolics partisan, I should point out the CLIM performance figures
have nothing to do with the ease with which applications are developed,
it just says that the resulting application will be pretty zippy on any
platform you choose.  I personally would still rather write the program
on my trusty Lisp machine, though.

    There are several concerns that can be usefully separated and dealt
    with differently if need be.  At the user interface level, where
    performance is less of an issue, I believe an UI system should specify
    EXACTLY the behavior of functions it support and have it behave
    EXACTLY the same on all platforms (modulo look and feel) without the
    user having to do things differently on some platform.  How it is
    implemented, whether the user need to do something different, etc.,
    should not be a concern.  Ie., if the function is supposed to pop up a
    window, then it should pop up the window without the user having to do
    anything else, period.  For example, a function like ACCEPTING-VALUES
    with the :OWN-WINDOW T option, should automatically pop up the window
    without the user having to do anything special, like setting
    *CLX-FORCE-OUTPUT* to T or doing a FORCE-OUTPUT beforehand for the
    window to appear.  It is very upsetting to use a UI function and have
    nothing happen. (It's too bad the manual I'm using is a Symbolics
    manual which is oblivious of buffered systems, but then a system that
    has portability as it's paramount goal shouldn't need more than one
    manual.)

That is the intention of CLIM, and as Dennis Doughty pointed out, it is
the *main* intention.  I know that it is sometimes hard to tell, but you
should be careful not to confuse bugs in the implementation with design
intention.  If there are other problems like the one you cite where there
are major functional differences between platforms (modulo look and
feel), you should send a bug report, not assume that it is stupid design.

    The other level of concern is performance.  Let me state my bias
    first, I'm one of those "lucky" programmers that never have to worry
    about performance, hence functionality and elegance are usually my
    prime concern.  To me, performance tuning and optimizations belong to
    the domain of compiler writers and wizards out to squeeze the last
    micro-second out of the CPU or await faster CPUs (which is not so far
    fetched in the unix world).  I don't have a good idea of what hooks
    are needed to satisfy these concerns and yet preserve all the other
    goals.  For the buffering question, my gut feeling is that, since it
    is mostly a performance issue (somebody raised the issue of
    synchronization), perhaps one should consider the strategy used in CL
    when dealing with performance, namely, via declarations/proclamations
    (eg., turn on/off all buffering).  The macro suggestion sounds ok,
    except that it is perhaps too simplistic, I think one need to also
    consider situation where abnormal exits occur - should the buffer then
    still be flushed, cleared, or the user be expected to take care of
    such situations, for example.  

I don't mean to sound *too* flip, but please give us credit for not
being stupid.  Many of the CLIMmers are long-time system programmers who
understand these issues intimately.

				   For faster graphical operations,
    perhaps one will have to go down to the window substrate level and
    conditionalize (#+CLX, etc.) them for portability.

I have some ideas for how to allow portable optimizations to take place.
The basic idea is that you call a function that constructs another
optimized function, and then you call the optimized function.  The
optimized function captures all of the state that is settable by
WITH-DRAWING-OPTIONS in an optimized form.  Of course, these functions
cannot be dumped/loaded, but it is still a productive area of thought.
For example,

(let ((dashed-red-line-drawer
	(make-optimized-drawing-function
	  draw-line* stream :dashed t :color +red+)))
  (dolist (line lotsa-lines)
    (let* ((x1 (pop line))
	   (y1 (pop line))
	   (x2 (pop line))
	   (y2 (pop line)))
      (funcall dashed-red-line-drawer x1 y1 x2 y2))))

DASHED-RED-LINE-DRAWER is a function object that captures STREAM (or
more likely, the actual stream-specific platform-specific object that
can be drawn on directly) and the decoded drawing state (including the
ink and dash pattern), and takes only the coordinates of the lines start
and end points as arguments.  It would not do any output recording and
would call the lowest level CLIM function to do the drawing, which is
probably the place that is intermediate between CLX (or Genera sheets or
whatever) and the lowest level advertised CLIM protocol function.  The
above code is portable (it would work on any platform), but (as I said),
you cannot dump/load DASHED-RED-LINE-DRAWER and expect it to work.  The
only faster alternative is to call CLX (or whatever) directly, and I
imagine that you would only gain a very small improvement over a good
implementation of MAKE-OPTIMIZED-DRAWING-FUNCTION.

    Nobody has addressed the issue of different streams yet, another
    environmental consideration.  CLIM seems to expect streams to be CLIM
    streams, ie., streams where graphical operations can occur.  Systems
    on Unix boxes in general start off with a listener where streams are
    not CLIM streams, there is a compatibility problem here I think that
    requires some policy decision or some convention. 

I think you need to raise this issue with the various vendors, as it is
an "integration" issue.  CLIM is not a least common denominator UI
toolkit.  It expects a minimum level of functionality, and tries very
hard to rig the environment to get that level of functionality.  The
minimum level of functionality includes support for graphics.

0,,
References:
Main Index | Thread Index