We have new feature requests like spellcheck support (#3814) or well-integrated syntax highlighting, and we want to be able to scroll text at 60 (or even 144) fps. It is worthwhile to take a look GtkTextView and its infrastructure to see what changes would make this easier and align things better with Pango.
In the past, some bits and pieces of this infrastructure were 'semi-public' for use in GnomeCanvas, and that still shows in places (even though we've made it all private now).
- Stores attributes and text inline, as opposed to Pango, which keeps attributes separate. GtkTextLayout has to reshovel things from the BTree representation into the Pango one whenever we need to create a PangoLayout for rendering
- Uses lots of linked lists
- Has scalability problems with long lines
- The tree is augmented with information such as position and size of lines, so it can answer questions such as 'Give me the line at y=200'
- Use a GtkTextBTree as backing store
- Has its own caching of log attrs (since they are needed for navigation). It would be nice if this could be somehow unified with the caching that GtkTextLayout does for render nodes - that computes log attrs as a side effect as well.
- The middle layer between GtkTextView and the BTree
- Creates and caches rendernodes for lines of text in the visible range
- Whenever it needs to create a rendernode, it has to first create a pango layout, which requires translating the segments of a line in the tree into text + pango attributes
- Packs a complete 'style' into one object, whereas Pango attributes go one-attribute-per-property. GtkTextLayout turns tags into a custom GtkTextAttrAppearance. One issue here is that pango assumes that attributes are cheap to copy around, and the appearance attribute is significantly heavier (copying it around involves copying a bunch of attached object such as GdkRGBAs and PangoTabArrays)