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

RE: CLIM philosophy wrt to X.

    Date: Mon, 26 Aug 1991 17:58 EDT
    From: Jeff Morrill <jmorrill@BBN.COM>

    The solution to the issue of buffered output, I hope, 
    is to put a big caveat in the CLIM documentation that 
    buffering is something that users must solve for themselves 
    via careful placement of FORCE-OUTPUTs.  This might ruffle
    some feathers for some purists who yearn for truly platform-
    independent behavior, but I am not a purist.

    I don't understand what WITH-BUFFERED-OUTPUT would do other
    than perform a FORCE-OUTPUT at the end.  I hope no one is
    suggesting that this macro will implement buffered output on 
    platforms that do not implement buffering in the native window 
    system.

The real intention of WITH-BUFFERED-OUTPUT is to allow programmers to
turn *off* output buffering on platforms that normally have it on.  That
is, WITH-BUFFERED-OUTPUT does not implement buffering itself, it just
allows it to happen on those hosts that already support it.

    I agree with Ken that DRAW-<thing>* is too slow already.  
    It is nice to have something fairly high level that takes
    every keyword imaginable.  But on the other hand, how often
    will anyone use all those things?  I have programs written
    in CLIM 0.9 which may do 100,000 draw operations at once, every one
    with the same options as the last one.  And every time
    through the loop, draw-<thing>* processes piles of stuff 
    (alu, transformation, stipple, ...) that only need to
    be processed once, if at all.  For such applications, we
    could use some low-budget functionality which could take
    advantage of what WITH-DRAWING-OPTIONS can set up.  Sometimes
    we use DRAW-<thing>*-INTERNAL, but even this is overkill for
    98% of the output operations.

You and I must write different sorts of programs, but I have only rarely
resorted to this level of I/O.  I imagine that your applications must be
display intensive, whereas mine are compute intensive.

    Right now, our use of CLIM includes a trap door to go
    directly to the native window system (CLX, Genera) for speed.  
    One gets acceptable speed, but at the cost of no output recording.
    Let us get away from adding yet another burden to the output
    protocol, and let us move toward a small kernel of low-level
    operations that do the simple things exceptionally well.  

WITH-BUFFERED-OUTPUT adds virtually no measurable cost, as DCPL already
pointed out.  It's simply a SLOT-VALUE plus a branch.

As for "exceptionally well", keep in mind CLIM is a high level UI
substrate. It imposes some measure of overhead on any operation.  The
higher you go, the more overhead you pay.  There is *no way* to avoid
this, no matter how hard you try.  At Symbolics on CLIM 1.0, we made a
pretty fair effort to reduce this overhead as best as we could, but the
mere fact that CLIM uses Lisp instead of C, CLOS instead of C++, means
that anyone will *always* be able to find a faster way, either by
sacrificing portality or features.  You can't have it both ways, even
though that would be nice.

0,,
Follow-Ups: References:
Main Index | Thread Index