[Top][All Lists]

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

Re: Emacs design and architecture

From: Dmitry Gutov
Subject: Re: Emacs design and architecture
Date: Fri, 15 Sep 2023 18:52:07 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 15/09/2023 12:32, Gerd Möllmann wrote:
I think it would maybe be good to think about the following:

Random thoughts about a parallel redisplay, from a height of 10 km.

What currently happens to bring changes to the screen is that redisplay
is called quite frequently in the course of processing input for
example.  Redisplay determines what part of the a "model" (buffer) has
changed, if any.  It makes sure that all info it needs to proceed is
available; think jit-lock, i.e. it calls Lisp. Because redisplay is
called frequently, it must minimize what it does, which is the reason
for the complicated optimizations there.

Whatever is done in the end, I think it would first be necessary to
change this general principle, so that layout/drawing whatever can
happen in parallel.  Without that, I suspect redisplay would get too
slow, or would finally collapse to a black hole by its complexity.

I think it'd be an interesting project to study how an existing Emacs could output into a web page. Or a web driver, etc. How a "toolkit port" into HTML/JS could work.

That system is historically more complex than what you described, including lots of callbacks, e.g. it might be possible to implement jit-lock using the 'DOMContentLoaded' and 'scroll' events.

Consequently, though, parallel layout has been historically a hard problem for web browsers, but the current engines do that, at least to an extend (I think that was one of the selling features of Servo, later incorporated into Gecko). Complexity is definitely an issue, though.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]