Re: Can we go GTK-only?

[Daniel Colascione]

On October 30, 2016 2:42:18 PM PDT, Stefan Monnier <address@hidden> wrote:
>> I wonder if we should let them run their event loops, in their own
>threads,
>> and separate that from the non-GUI events like subprocesses and
>timers, and
>> from Lisp evaluation, as much as possible.  For that matter, some of
>the
>> subprocess handling could probably use helper threads, like for TLS
>> encryption and decryption work.
>
>Ideally, yes, I definitely think we should split the Emacs process into
>various threads:
>- some threads for the GUI.
>- one thread for the Elisp engine (which receives events from the GUI
>  threads among others).
>
>So the GUI thread would handle the expose events, read-locking the
>matrices, while the redisplay would run in another thread,
>write-locking
>those same matrices.

Agreed. That's basically how IntelliJ works too. We can do even better too: 
there's no reason these parts need to run in the same process it even the same 
machine. 

But this scheme won't really eliminate the coupling between redisplay and lisp 
though, since the former calls into the latter. The redisplay thread has to 
block waiting on lisp anyway.

Anyway, I strongly encourage you to look at the React Native rendering model. 
It's the most elegant way I've seen of constructing GUIs in general.

The key insight there is that we shouldn't have redisplay *lock* the display 
matrix and render it. The lisp universe should send a *copy* of the matrix set, 
then go about its business. This way, redisplay can go display that copy and 
everything is decoupled. You turn the system into an Erlang like message 
passing environment.

.