Re: Developing a new text editor widget?

[Christian Hergert]

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

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_spawn_async_with_pipes is not thread safe

[Alan Coopersmith]

On 06/ 3/16 08:31 AM, Chris Vine wrote:

On Fri, 3 Jun 2016 12:30:04 +0100
Simon McVittie  wrote:

There's a gap here between the theory (GLib mostly has only POSIX
requirements) and the practice (glibc malloc is designed to allow
things POSIX doesn't, and this useful functionality would be
difficult to achieve without that). In principle GLib could call
opendir() on /proc/$pid before forking, then read it in the child,
but readdir() isn't async-signal-safe either. Doing the reading in
the parent isn't a solution, because the parent is potentially
multi-threaded, so it could be opening and closing file descriptors
in other threads (racing with the readdir()).

In principle the parent could read the new child's fd table and write
a list of fds into a pipe, for the child to close them all or set
them all close-on-exec, while the child waits for EOF on that pipe
before proceeding with the close and exec operations... but that
seems fairly horrible.

I think what we really want here is *BSD closefrom(), which at least
FreeBSD documents as async-signal-safe. Unfortunately, Linux doesn't
have that system call. libdbus would have the same issue on platforms
that don't have closefrom().


For the g_spawn* family of functions, glib has in effect adopted (on
linux platforms) an unspoken glibc dependency.  I do not know what the
position is on windows and solaris.  (Possibly solaris doesn't count
any more.)


I'd like to think Solaris still counts - certainly we're trying to support
modern glib & gtk3 applications in Solaris 12.   We do have closefrom()
though ours isn't documented as async-signal-safe or MT-safe.

I've wondered before how hard it would be to wrap the g_spawn* functions
around the posix_spawn API's we prefer, but have been too busy getting
our packages updated to more current versions to work on that.  We do
have a MT-safe posix_spawn_file_actions_addclosefrom_np() in libc we
could then use.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Developing a new text editor widget?

[Sébastien Wilmet]

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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Developing a new text editor widget?

[Sébastien Wilmet]

On Sun, Jun 05, 2016 at 03:15:30PM -0400, Rena wrote:
> As an application developer, my main gripes with GtkTextView have been:
> 
> 1. The view/buffer model. I expected that the view just asks the buffer for
> text, and I could supply a custom buffer object that generates text on the
> fly. In reality it seems I have to use a GtkTextBuffer and fill it with the
> text I want to display, and manually respond to cursor movements by
> modifying the buffer. It rather defeats the purpose of having a view/buffer
> model at all.

The view is not the only user of a buffer. There can be scanners that
scan the buffer, to do various things such as highlighting the syntax.
The buffer/view split permits in theory to have several views for the
same buffer. Lazy loading of the buffer content is something separate.

> 2. Difficult to compute how much text will actually fit in the view, when
> varying character sizes (especially heights) are involved. This relates to
> #1, since I'm not putting text into a view, I'm putting it into a buffer
> which doesn't know much about how the view is going to render it. This
> makes it difficult to know how much text I need to supply. (I can usually
> get away with over-estimating and supplying more than enough, but then when
> the cursor is moved down at the bottom of the view, it wants to scroll, so
> I have to handle that... also I hadn't even thought until now about what
> "select all, copy" will do in this case.)

I don't think GtkTextBuffer was meant to be used like that, despite its
name.

> 3. No way to control the positioning of text and/or movement of the cursor.
> When implementing a hex editor widget, I wanted to display data in a format
> like "__00_00_00_00__00..." (where _ is a space), but have the
> cursor skip over the spaces. I could find no way to achieve this except by
> (again) manually handling all cursor movement events, trying to figure out
> what the best valid position is for where it's trying to go, and putting it
> there. I had hoped I could either tag the spaces to say "have the cursor
> skip over this", or add a "margin-right" attribute to the digits like I
> would in a web page, so that spaces would be added without using an actual
> space character. (Although in the latter case I'd have to have a custom
> "copy" handler that renders the text *with* spaces for the clipboard, so
> that might not be so good either.)

I think it's possible to implement virtual spaces with a utility class.
It's probably not straightforward, but it should be feasible. I also
need virtual spaces in gCSVedit:
https://sourceforge.net/projects/gcsvedit/

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list