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

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

>     Date: Mon, 20 Dec 1993 13:16 EST
>     From: Peter Karp <pkarp@ai.sri.com>
> 
>     I also find CLIM (1.1 Lucid) text drawing to be much slower than I'd
>     like.  Simply calling clim:draw-text* on short strings (5 characters),
>     with each one wrapped in a different presentation, can take a couple
>     of seconds on a Sparc 10 to display a couple hundred items.  It is
>     this kind of marginal performance on simple tasks that makes people
>     wonder if they should be using CLIM at all, since X applications do
>     this kind of thing almost instantaneously.  
> 
> Hmm, I wasn't aware that X toolkits transparently supported
> presentations and output recording.
> 
> Or if I may be less snotty, in CLIM you get output recording and
> presentations as part of the basic functionality.  If you don't want
> them, you have to explicitly turn them off.  So what you said is
> definitely and apples-and-oranges comparison.

Believe me, I appreciate CLIM's high-level capabilities or I wouldn't
be using it.  But I believe that a measure of high-level snottiness
has gotten in the way of getting CLIM to do simple things quickly.
No, X doesn't have presentations, but they certainly do have ways of
putting text on the screen so that you can click on it that work MUCH
faster than CLIM does (not being an X programmer (thank God) I have no
idea how they do it).  Since I'm not a CLIM implementor, I have no
idea why presentations are so slow, but since they only seem to be
typed objects with a bit of info such as screen position thrown in,
why do they take so darn long to deal with?

> 
>     Are any of the  CLIM vendors putting effort into optimizing these kinds
>     of simple operations?  I strongly advocate such work.
> 
> CLIM:DRAW-TEXT* wrapped in a presentation is not a "simple" operation.
> 
> Are you asking for an example of a sophisticated sort of output
> record that records one big glob of text, and then rapidly generates
> presentations on the fly so that the overhead of creating the
> presentations is distributed over time?  That would make text output
> faster, but it would require a more primitive level of programming to
> use it.

For most of our applications we don't care about big globs of text.
We just want the operation of drawing a short piece of text (5-50
chars) inside a presentation to be MUCH faster than it is.  I don't
know enough about CLIM to know why this takes so long.  Perhaps it is
the generality of all the things one can do with a presentation.  If
users identified subsets of the complete presentation functionality,
would that help you implement a stripped-down presentation that is
faster?

I'll note that even drawing text with NO presentation recording seemed
quite slow in some of my experiments of a year or two ago, apparently
much of the time was going to CLIM's text-measurement operations.

Peter
Follow-Ups:
Main Index | Thread Index