Re: Implementing child frames on terminal

[Akib Azmain Turja]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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,

I don't think so.  I tried to hard-code last_visible_x to 40.  Then I
compiled and started Emacs and found that the lines of *scratch* buffer
wrapped at 39th column (and the 40th column being the continuation
glyph).

> because no one said that the clipping happens on the margin

It may happen.

> (and most
> windows don't have margins anyway).

Really?  It seems that line numbers are also unaffected by that
last_visible_x.

>
>> 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.

IIUC, we won't need additional code.  Because those garbage glyphs are
outside of the frame's glyph matrix, so the terminal display code won't
notice them at all.

I think we are all trying to do premature optimization.  Do we bother
whether a character is clipped on X?  AFAIK no, and that's more costly
than doing the same on terminal.  I think we should first make it work
and then talk about optimizations, that's better than rejecting all the
proposed ideas claiming they are inefficient.

Or is there any real reason to optimize?

>
>> 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.

Thanks.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

signature.asc
Description: PGP signature