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

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

    Date: Tue, 21 Dec 1993 13:53 EST
    From: Peter Karp <pkarp@ai.sri.com>

    >     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...
    > 
    > 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*.

    I'll come back to this point again.  Maybe "simple" is the wrong
    concept for us to be arguing about.  I claim that it's incredibly
    common that both CLIM and X applications want to quickly draw lots of
    pieces of text to the screen that are all mouse sensitive.  X
    applications seem to be able to do this MUCH faster than CLIM can, so
    any manager type person who looks at X and looks at CLIM immediately
    wonders why CLIM is so slow at doing something that so many
    applications obviously need to have.

    Here's another idea.  Output records in CLIM are used for both
    computing mouse sensitivity of presentations, and for refreshing the
    display (anything else?).  Would it be worthwhile to create two new
    classes of output records, each of which is only useful for one or the
    other capabilities?  So I could get mouse sensitivity at the price of
    not being able to refresh the screen quickly in a way other than
    simply reinvoking my display code.  Would this speed up my display
    code? 

There are already two classes.  Vanilla text output records are, in
fact, only used as a "display list" for doing scrolling and display
refreshing.  Presentations are a special class of output record that
have some child output records (such as, say, some text), an object,
and a type.  I think that my suggestion from before, whereby you can
do on-the-fly generation of presentations, is probably the most
fruitful path to pursue.
References:
Main Index | Thread Index