Re: Developing a new text editor widget?

[Christian Hergert <christian hergert me>]

On 06/11/2016 02:47 AM, Sébastien Wilmet wrote:
> /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).

Sure. O_TMPFILE/unlink() is just handy to avoid leaking filenames.

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

As long as we can treat them as non-fractional boundaries then this is
fine. If not, it just affects the column index, not the line index and
somewhat complicates the "what column am I on" question.

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

This is not true. If it were, I would be able to open gtktextview.c and
scroll to the bottom immediately upon restoring cursor position like I
can in vim.

You are left with either jittered scrolling (when you come across more
complex portions of text the layout/draw cost is greater) or you decide
to stall until the calculation is far enough that you can animate there
smoothly.

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

Then you had too small of resolution for it to be an issue. It's barely
keeping up at 2560x1440 at 1x and even worse at 2x with QHD. The
scrolling performance is incredibly timing sensitive. If you have more
complex blocks of text, it gets worse. Being off by a ¼ of a millisecond
still results in a dropped frame which is jarring.

This is exacerbated by the laziness in the pixelcache design. When we
have a damage or require a full draw (happened *a lot* until the recent
GSV changes I put in place) we need to draw roughly 2x the visible area
and all within the time period that the FrameClock normally saw for our
normative drawing cost (ie: memcpy). Anything we do to improve this
design (instead of replace) will likely result in predicting draws
sooner to ensure the FrameClock schedules additional time for drawing.

-- Christian