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

Re: reducing time overhead of text display (in 1.1)

    Date: Mon, 20 Dec 1993 19:59 EST
    From: Peter Karp <pkarp@ai.sri.com>

    Thanks for the interesting summary of what happens when you do a
    draw-text*.  I wonder if you know the amount of time consumed by each
    of the half-dozen operations you described.  That seems like a crucial
    thing to know before starting to optimize it.

Yes, I do know how much time various things take.  A lot of this
code is already quite optimized.  Of course, there is almost no code
that cannot be improved, but one does tend to run out of steam after
a while.

    I like the idea of having a way to batch output records.  Copying ink
    and stream info into each output record seems like a real duplication
    of info...  

That doesn't cost much, really.  The time-consuming parts are the
measuring of text size and keeping parent output records and scroll
bars up to date.

    Something I suggested a long time ago is that in some applications, in the
    course of drawing text, the user has to measure its size, then do 
    an appropriate draw-text, at which time clim also measures its size!
    So an expensive operation gets done twice.  If there's a way to eliminate
    this redundancy that could save some time...

I've thought of this, too, but the problem is that there is no good
place to cache the information.  Even a simple one-entry cache is
not easy, because there are quite a few things that can affect the
result of text measurement operations.

    I just don't think that users should have to go through the hairiness of
    defining their own output record types to make relatively simple things
    run fast...

[Added back clim@bbn.com so I can publicly make my next point.]

I have to repeat that text presentations are not relatively simple.
They are, in fact, quite complex.  You are being fooled into thinking
they are simple because they are *simple to use*.

If what you are really asking for is a package that does fast text
output and produces "on demand" presentations, then that is a reasonable
thing to want.  But be warned that the programmer interface will be much
more complicated than what you have to use now.

In my opinion, one of the really good things about CLIM is that, not
only are simple things simple to do, but a lot of complex things are
simple to do as well.  (Check out DEFINE-DRAG-AND-DROP-TRANSLATOR.)  And
one of the really good things about CLIM 2.0 in particular is that we
spent enough time re-designing the lower-level layers that, when some of
those complex things break down in some way (such as performance), it is
usually quite straightforward to slide in an implementation of your own
that has characteristics that are better for you application.
Follow-Ups:
Main Index | Thread Index