Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  ibluefocus@outlook.com
> Date: Wed, 13 Jul 2022 20:33:52 +0600
> 
> > The way redisplay of a window works, it starts by determining how wide
> > can each screen line be before it overflows the right edge of the
> > window.  The result of this is the member of 'struct it' called
> > 'last_visible_x'.  It is computed once (see init_iterator), and then
> > used everywhere when we need to decide whether there's place in the
> > screen line for one more glyph.
> >
> > So to support the above, we'd just need to modify the calculation of
> > last_visible_x in init_iterator such that it takes into consideration
> > the edge of the parent frame.  And that shouldn't be hard, given that
> > we know the offset of the child frame from its parent frame.
> >
> 
> What do you mean?  Set last_visible_x to the last x position not
> clipped?  That won't work, since last_visible_x has no effect on
> margins AFAIK.  Same for first_visible_x.

You mean, the display margins?  If that is the problem that bothers
you, then yes, the functions in dispnew.c that calculate the
dimensions of each window will have to take the clipping into account.
And again, this calculation happens just once, in the beginning of a
redisplay cycle, and only if needed (i.e. only when the previously
calculated dimensions no longer fit).

But last_visible_x will still need to be adjusted as I outlined,
because no one said that the clipping happens on the margin (and most
windows don't have margins anyway).

> I have another idea, we can make the glyph matrix memory larger than the
> top-level (i.e. not a child) frame:
> 
> --8<---------------cut here---------------start------------->8---
> +--------------------------------------+
> |+------------------------------------+|
> ||                                    ||<<< glyph matrix memory
> ||<<< frame glyph matrix              ||
> ||                                    ||
> ||                                    ||
> ||                                    ||
> ||    +-----------------------------+ ||
> ||    |<<< child frame glyph matrix | ||
> ||    |                             | ||
> |+----|.............................|-+|
> |     |                             |  |
> |     +-----------------------------+  |
> +--------------------------------------+
> --8<---------------cut here---------------end--------------->8---
> 
> According to the figure above, rendering glyphs for part of child frame
> outside the top-level frame's edges won't cause any error because it
> will write to allocated memory, but still those glyph won't appear on
> the glass because they are outside the glyph matrix of the top-level
> frame.

Why produce glyphs that will never get written to the glass?  It's
just a waste of cycles.  And it isn't for free: we'd need to have code
that checks whether a glyph should or shouldn't be written to the
screen, because writing it outside of the terminal could have bad
effects.

> Do you have a list of functions that directly writes to glyph matrix?
> It is much easier to work with function than to work with dynamic
> memory.

They are too many, but you can start from the PRODUCE_GLYPHS macro.