Re: Terminal matrices

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> Date: Sun, 19 Jan 2025 09:58:09 +0100
>> 
>> Good, but to achieve this, combine_updates creates a second pair of
>> glyph matrices in addition to the existing frame matrices, which I've
>> called terminal matrices. These terminal matrices are created the first
>> time combine_updates finds a visible child frame that must be displayed,
>> 
>> >From then on, terminal matrices are used for the update by setting the
>> frame's current and desired matrix to the terminal matrices. After the
>> update things are restored to "normal".
>> 
>> What is displayed on the terminal in found in the terminal current
>> matrix, and what should be displayed is in the terminal desired matrix.
>> And there's the rub: the construction of the terminal desired matrix
>> _requires_ that I copy the frame desired matrix to the terminal desired
>> matrix (the part that is enabled_p). That includes a memcpy of the
>> glyphs. And in the worst of all cases, say when using my full-screen
>> eMacs on MacOS :-), this is in bytes on my arm64
>> 
>>   (* (frame-width) (frame-height) 56)
>>   743008
>> 
>> It's not that it is always so much, usually it's probably much less, but
>> anyway. And it is _unavoidable_ to achieve the independence of the rest
>> of redisplay. At least I have no idea how to avoid it. Let me say it
>> that way.
>
> How much time does it take to memcpy the above amount of glyphs?

1 Mb on an M1 pro takes ca. 0.4 ms, worst. See my other mail in this
thread which has a C file to measure this.

> Can we avoid doing that unless there are in fact child frames?

As long as one doesn't use any child frame on a frame, combine_updates
doesn't use terminal matrices. As soon as 1 child frame is seen,
combine_updates switches to terminal matrices and it stays that way.

It's unclear to me if it is worth it switching back to frame matrices.
Imagine Corfu being used. I think one would end up switching back and
forth. The switching back, BTW, would require such a memcpy, too.