FYI: GtkText design ideas update

[Derek Simkowiak <dereks kd-dev com>]

>  I plan to cache one screen's worth of text (in rendered pixmap form)
> both upwards and downwards, so verical scrolling will be smooth.

	I've found a great document on X performance considerations at
http://www.rahul.net/kenton/perf.html.  After reading it, I now realize
how ludicrous the idea of a pixmap buffer is for a text editor, and I feel
stupid for having mentioned it.  It's not like *everybody* has megabytes
of spare memory to give to a text widget :).

	I am, however, still playing around with the idea of rendering the
onscreen text to a pixmap first.  The pixmaps would only be the size of
the text itself--i.e., a blank line would not have a pixmap, and a line
consisting of the '{' character would have a pixmap only a few pixels wide
and tall.

	But this means for a bad case scenario--a full-screen GtkText
filled text characters on every line--would still take a huge array of
pixmaps.  At 1024x768x16bit, that'd be 1.5 Megs of RAM wasted.  Actually,
since the whole pixmap idea is for lines which require scrolling, it could
be even more than that...  I haven't thought about how to handle really
long lines of text.  And this scenario would require some fairly
complicated pixmap coordinate-handling code.

	I just looked at Nedit's source, and its text drawing function
does not use a pixmap at all.  I'm about ready to abandon the whole idea
of buffering with a pixmap altogether, and just redraw text as necessary
when scrolling.  Perhaps, to facilitate a 'smooth scrolling' feature, I'll
keep the top and bottom lines of text in a pixmap, but that will be it.

	So now the question becomes how to efficiently calculate which
areas of text need to be redrawn in a horizontal scroll...


--Derek