Re: Developing a new text editor widget?

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]