CLIM mail archive
[Prev][Next][Index][Thread]
RE: CLIM philosophy wrt to X.
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.
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.
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.
jeff
0,,
Follow-Ups:
Main Index |
Thread Index