Re: Terminal matrices

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> If you're interested, I've pushed something new. Now with GLYPH_DEBUG
>> support, and even more rough in the code. But I guess at this point only
>> the idea counts to see if it flies. BTW, what I had yesterday was kind
>> of right, but I overlooked two things, most notably the window matrix
>> mirroring.
>
> Works well here.  Please move it to master so we can get immediate
> feedback from corfu/posframe users (I don't use them).

Thanks Martin, that's good to hear!

There are some things open, though. I'd have at least take a look at
menus. Let me see, no they abort with GLYPH_DEBUG, a child frame open
with C-l, and clicking on the menu bar. Also, tab-bar maybe, I'll have
to check how that is implemented.

Another more basic question is a possible performance impact that I
don't have an idea how to avoid. Let me describe a bit how things work
with terminal matrices.

In a call tree containing combine_updates, everything above the call to
combine_updates and everything after it returns uses frame matrices, as
it always was. All tty frames, roots or children, are completely
independent of each other, and know nothing about each others display,
whether they are partially obscured by other frames or anything like
that. It is as if each of these frames was running in a separate
terminal. I find that very appealing because the complexity is for the
most part localized.

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.

So, hm. Maybe we should get some impression first if that is noticeable
in interactive use?  🤷

And I'll tackle the remaining problems with menus and son on once it's
certain it's acceptable.

Sorry for the long mail.