Re: "Final" version of tty child frames

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> x eventually becomes 73 (759 - 686) which is what I see.  What could I
>> do to make the check at the top succeed?
>>
>> martin
>
> I'm not sure that would be sufficient.
>
> The basic problem seems to go like below. Sorry if that gets a bit
> complicated :-).
>
> For ttys, I've introduced "frame-based" redisplay. The glyph producing
> part of redisplay always works on windows, both on GUIs and ttys. On
> GUIs, windows have their own glyph matrices which are independent of
> each other. The frame has no glyph matrices. On ttys, frames _have_
> glyph matrices that are allocated for them, and window glyph matrices
> are sub-allocated from frame matrices. IOW when I look at a glyph G in a
> window matrix on a tty frame, G is actually in the frame matrix.
>
> I did that frame-based hocus pocus to minimize terminal output by being
> able to determine if one can scroll part of the display. It's a long
> story. The important part here is that a root frame's current matrix
> _must_ contain what's displayed on the terminal for the whole update
> part of redisplay on ttys to work.
>
> Good.
>
> Now let's assume we have a root frame R and a child C, and we are in the
> update phase of redisplay.
>
> If C is _not_ displayed, R's current matrix reflects R's contents; for
> all windows on R, a window's current matrix corresponds to what is
> currently displayed. I've used that fact to speed up redisplay. I didn't
> remember set_cursor_from_row specifically, but it's one of those places,
> as one can simply see from the fact that it looks at glyphs from R's
> current matrix.
>
> If C _is_ displayed, the combine_updates step in dispnew.c manipulates
> R's current matrix to include C. This is needed because of what I said
> above: R's current matrix must be what is displayed on the terminal. But
> now, for all (x, y) on R displaying C, the glyphs now actually re copied
> fro some window on C!. Or, said the other way 'round, the assumption
> made that some window's current matrix can be used in cases like
> set_cursor_from_row is no longer valid!
>
> So, that's the problem, or what I think it is. A bit difficult to
> describe :-/. It's sophisticated :-)

Let me just quickly add something that came to my mind, namely that one
could tackle the problem in two different ways:

1. In xdisp.c, so that current matrices are not used in tty frames
having visible child frames and blah blah.

2. In a completely different way that a avoids the problem altogether.
That was the idea I had a few minutes ago:

In combine_updates, currently the root frame's current matrix is
modified by copying glyphs from child frames to it. That makes the
problems.

What if we didn't do that? Instead, build a new matrix, let's call it a
combined matrix, that is built by first copying the root frame's matrix,
and then the child frames' matrix. That would leave the root's current
matrix alone. The combined current matrix would then represent what is
currently displayed on the terminal.

It's just an idea, not a complete design. Other random thoughts

- Need only be done if child frames are visible

- Maybe a lot of work in the call tree below combine_updates which
  currently only knows about current/desired matrices. But maybe one
  could cheat and replace current/desired matrices with
  combined-current/desired matrices temporarily?

- what about mirror_line_dance or what the name is.