|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |