CLIM mail archive
Re: reducing time overhead of text display (in 1.1)
Date: Tue, 21 Dec 1993 13:53 EST
From: Peter Karp <email@example.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
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.
Main Index |