Re: Gtk::Text widget

[Derek Simkowiak <dereks kd-dev com>]

-> > 	The big one is Havoc's new text widget, originally based on the
-> > TkText widget.  It is very featureful, and Owen added Pango support, but
-> > it is a huge memory hog (just like the TkText widget).
-> 
-> I think "memory hog" is an overstatement; last time I measured it the
-> overhead without tags was less than 3 bytes per character, including
-> all memory used by the GTK process

	Whoa!  3 bytes per character?  Whatever happened to the 40-byte
overhead of every tag toggle (and every Line parent node)?

	Also, what about search (esp. regex) operations?  I think regex
searching is a requirement of a good text widget; this is easy to do on a
gapped text buffer, but requires splicing together the entire character
buffer when your text is in a tree (does it not?).  If I remember
correctly, the TkText has a simple search that it does by looking at the
characters of the next node/line but no regex search.

-> unrelated to the widget). Using lots and lots of tags could double
-> your memory usage, but probably not much worse than that.

	Can you post your numbers from MemProf?  Both with and without
tags, if possible...  I'm really very curious about this.

	I don't currently have a dev environment where I can muck up my
Gtk+ libraries/headers with the CVS version, so I haven't seen it in a
while.

-> Anyway, the full story IMHO is that yes the widget uses more memory
-> than it has to for simple buffers, but in exchange you get a robust,
-> scaleable widget.

	How does your new-and-improved version handle Unicode?  I've been
planning on letting the user select between an 8-bit (ASCII), 16-bit
(UCS-2), and 32-bit (UCS-4) gapped text buffer for internal storage.  At 3
bytes per character, you must only be using one byte for encoding?

	(Or are you using UTF-8 internally?)


--Derek