[Top][All Lists]

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

Re: Emacs design and architecture. How about copy-on-write?

From: Dmitry Gutov
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Thu, 21 Sep 2023 14:10:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 21/09/2023 13:48, Ihor Radchenko wrote:
Dmitry Gutov<dmitry@gutov.dev>  writes:

I think that there is at least one way to address long lines using
asynchronous redisplay - put a placeholder on the problematic line and
continue calculating the actual rendering in the background instead.
That will not force us to compromise between rendering time and
accuracy, as we do now, with long-line-threshold.
Until you're laid out the long line, you don't know which screen line it
will finish at, or at which height specifically (it might have images,
or taller text due to faces, etc). So you can't render the remainder of
the buffer either.
What I had in mind is the processing to happen in two stages: (1)
calculate "quick-and-dirty" layout; (2) start calculating "accurate"
layout. If calculating "accurate" layout takes long time, go ahead and
draw the "quick-and-dirty" version on the glass, while "accurate"
version continues being computed in the background.

Of course, this threshold should be configurable.

Similar approach might be used to render mode lines - render a
placeholder until it is fully calculated, keeping Emacs responsive.
I hope by "placeholder" you mean the previous rendered image of it.
More precisely, what I had in mind is the old glyph matrix + some
indication that the rendering is not up-to-date (like classic sand clock

Any visible indicators of incomplete layouts or "not yet updated" icons are going to be a visual nuisance if the refresh speed is still above 5fps. So we should be careful with those.

And even the "slow" mode-line packages still manage to maintain at least 5fps, I believe.

reply via email to

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