Re: Q: child frames on ttys

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
>> Date: Mon, 02 Sep 2024 10:37:37 +0200
>> 
>> Just wanted to mention that I had an idea yesterday how to solve that
>> problem without making broad changes outside of the tty code. The idea
>> is to write a function that maps an (x, y) position in a
>> matrix the frame holding the realized face at that position.
>
> Sorry, I don't understand: a function mapping a position to what?
> 'struct face'?  If so, and unless the function is cheap enough,
> wouldn't that make redisplay slower?

Yes, in th4 end it's a struct face, that's right. And it's pretty cheap.
Of course famous last words and so on. I haven't implemented it yet.
And it affects tty frames only which I find nice.

The thing is intended to work like this:

Suppose we have only one root frame and a number of overlapping child
frames on top of it. All these frames are considered independent of each
other like on a GUI. Each frame has its own frame matrices.

For each frame we build window matrices as usual, and for each frame we
build the corresponding frame matrix.

New is building the frame matrix and writing to the terminal are
separated from each other. Writing to the terminal happens only for the
root frame, after first combining all the frame matrices we deal with by
copying glyphs from the child matrices, in reverse z-order.

The combination step computes z-order and the intersection rectangles of
child frames with the root frame to know what to copy where. That's how
I do it now.

The new plan is to record these rectangles as a list of (child-frame
rectangle). Probably not Lisp lists, don't know.

Now, when writing glyphs at some cursor position (x y), we call
turn_on_face (frame, face_id), where face_id comes from some glyph. We
consult the list above, and determine the topmost in z-order child-frame
from which this glyph was copied, if it was. That frame contans the face
cache for the face_id of the glyph. 

When there are no child frames, the list is empty, and it boils down to
a function call instead of simply using FACE_FROM_ID. I'd say that's
cheap.

If there are N child frames, we have to test N times in the worst case
if (x y) in inside a given rectangle, which is 4 integer comparisions
each. And N will be small, typically N = 1.

Seems workable to me, but one has to wait and see of course.