Re: Developing a new text editor widget?

[Christian Hergert <christian hergert me>]

On 06/05/2016 10:35 AM, Sébastien Wilmet wrote:
> It would indeed be really nice to have such an implementation, to
> support very large files and very long lines (GtkTextView currently
> doesn't support well very long lines, there is a performance issue). But
> writing a new text widget is a major undertaking. For example, just for
> the mmap idea, is it possible to mmap a remote file? (that's a real
> question, I actually have never tried). And what about encoding
> conversion if the file isn't UTF-8?

You wouldn't want to mmap() the whole file, because that would still
limit how large of a file you can open on 32-bit systems. You would want
mapping windows with a page replacement strategy. Once you get this far,
mmap() is simply an optimization over a page/extent read.

You need to iconv/etc the whole thing sequentially and therefore must
read in the whole file upfront. However, you can do this and then
proceed as normal with the alternate file afterwards (using O_TMPFILE or
tmpfs backed fd).

> There was also some talks about a monospace-only textview. But even in
> source code, a string or comment can contain text in any language. So
> having good i18n support as an option can be a big advantage when
> choosing a text widget or toolkit.

Are there situations where the character is larger than a single cell?
Do we want to support widgets interleaved with characters? I know I'd
like widgets *between* lines, but not sure I want widgets between
characters/words on a line.

LTR/RTL is one thing, but that can still exist while being monospace.
The important performance gain we want is to make the operation of
converting line,column → x,y as close to O(1) as possible. We likely
still need an index for line positioning though, because I'd like to be
able to insert widgets in-between lines. (Imagine showing IDE fixits as
a list of items underneath the line they fix).

We definitely want both an line and a column index going forward though.

> For source code, GtkTextView is really not that bad IMHO. Normally
> source code doesn't trigger the very long line problem (and even, this
> problem in GtkTextView is fixable by internal refactorings, although
> nobody tried recently AFAIK). And source code is contained only in very
> small files, it is not a problem to load e.g. 20k lines in memory.

There are a few things that it is really bad at.

You have to scan linearly from O..n to determine line height. There are
all sorts of hacks to do this upfront in high-priority idles. It's why I
still can't open a file, and scroll to a line number like 1000 correctly
without retrying a bunch of times.

If we could sacrifice 100% correct scrollbar correctness (really, its
not that big of a deal) we could avoid this problem. Just estimate by
byte offset the Y position, and make calculated offsets in the Y
position b-tree/treap/index relative to it's parent node.

> And if a new text widget is written, there is the question about the
> API. If the API is different, porting all the applications to it would
> also be a huge amount of work. The GtkTextView API is not that bad, I
> find it convenient to use, even if it could be modernized or improved
> here and there (leverage CSS, better support multiple views, and a few
> smaller things). So, if one day a new text widget is written, I think it
> would be a good idea to not diverge too much from the GtkTextView API.

Mostly agree, but I wouldn't be willing to lock myself into an API
choice until the problem is solved.

As you said at the start, this is a massive undertaking. While I have
ideas on how to implement this, I need to be realistic with my time and
I have a lot of work in front of me right now.

The main thing I'd like to learn at the hackfest is what constraints
must we take on to do fast text scrolling with GSK+(GL/Vulkan/etc). This
pixelcache copying on every frame is really hard to optimize.

-- Christian