Re: Developing a new text editor widget?

[Sébastien Wilmet <swilmet gnome org>]

On Sun, Jun 05, 2016 at 12:33:20PM -0700, Christian Hergert wrote:
> 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).

/tmp is mounted in RAM on some distros, AFAIK. Maybe a better place is
~/.cache/, so opening a 8GB file is feasible (not sure it is useful
though, but people coming from Windows expect to be able to use a GUI
tool for everything).

> Are there situations where the character is larger than a single cell?

Yes I think.

In French there is æ and œ, those should ideally be displayed as 1.5x
the size of a char. Or there is also "…". But those are still entirely
readable in monospace. But I think in other languages, there are
characters that should take 2x the size of a cell.

> > 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.

When loading a large file (e.g. 20 MB), we indeed see GtkTextView busy
computing its size. But for a file of 10k lines, there is absolutely no
problem.

In gedit-tab.c, scroll_to_cursor() is an idle function.

> 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.

When I was a heavy user of gedit a few years ago (for developing in
Vala), I've never seen the scrolling performances as a problem.

--
Sébastien