> he believes that you write the text
> *once* into a background pixmap and then scroll it around. I can't
> believe this is true. If indeed it isn't true you should perhaps
> explain why it takes so long to read the RFC in (is it just slow ftp
> or are you doing lots of processing?) and whether it is true that the
> X server should be chewing up CPU?
Actually, I don't think it's a pixmap. What every X text widget I'm
aware of does, is this: It puts up a single window, and figures out
what lines of the text to paint in that window. When the user scrolls
the text, it re-figures the lines, and repaints the window. Thus it can
handle text of arbitrary length, with relatively small use of X Window
resources, even if backing store is enabled; in fact, backing store
works well with this scheme.
What I think xmosaic does is: it creates both a fixed window as above,
then creates a huge-ass window as a child window. It connects the
scrollbar to the child window, and allows the user to scroll the child
window around, instead of scrolling the text around. This is a *much*
simpler way of doing things, but now X *will* allocate an internal
backing pixmap for that child window, even without backing store, and
without all of it being exposed. So you're using one huge amount of
memory. And this is just to avoid using the Motif text widget? As I
say, this kind of approach would work OK on X for a HyperCard-like
system, but not for a scrolling system.
Excerpts from mail: 25-Feb-93 Re: xmosaic experience Marc
[email protected] (1288)
> Parsing a document that long and finding out how to break it up into document
> pages just plain takes a while
Hmmm, the document was plain text. Where's the parse? And of course if
you didn't have to break it into document pages...
Bill