unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Questions on glyph matrices used for rendering frame in terminal
@ 2022-07-04 17:26 Akib Azmain Turja
  0 siblings, 0 replies; 6+ messages in thread
From: Akib Azmain Turja @ 2022-07-04 17:26 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]


Hello hackers,

I'm currently trying to understand how Emacs builds the desired matrix
of a frame from the desired matrices of the windows in it.  But I can
barely understand anything.  I would be grateful if someone familiar
enough with it takes time to answer my following questions.


1. What's the purpose of the following in
build_frame_matrix_from_leaf_window?  "frame_row->used[TEXT_AREA]" will
always end up being equal to "window_matrix->matrix_w" after processing
the right-most window of the row.

--8<---------------cut here---------------start------------->8---
      /* Set number of used glyphs in the frame matrix.  Since we fill
         up with spaces, and visit leaf windows from left to right it
         can be done simply.  */
      frame_row->used[TEXT_AREA]
	= window_matrix->matrix_x + window_matrix->matrix_w;
--8<---------------cut here---------------end--------------->8---


2. From the documentation of make-terminal-frame:

> Note that changing the size of one terminal frame automatically
> affects all frames on the same terminal device.

But why?  Do they share glyph matrices, since only one of them is
visible at a single time?


3. Why clear the desired matrix in build_frame_matrix?  As I understand,
that would clear the glyph matrices of windows the frame, because window
desired matrix shares memory with frame desired matrix, and its seems
like build_frame_matrix is called after window desired matrices are
built.

--8<---------------cut here---------------start------------->8---
  /* Clear all rows in the frame matrix covered by window matrices.
     Menu bar lines are not covered by windows.  */
  for (i = FRAME_TOP_MARGIN (f); i < f->desired_matrix->nrows; ++i)
    clear_glyph_row (MATRIX_ROW (f->desired_matrix, i));
--8<---------------cut here---------------end--------------->8---


4. And one more question: why don't Emacs is use the window feature of
ncurses despite depending on it?  Is it inefficient or lack of any
feature?


Thanks in advance, and apologies if this is not the right place to ask.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Questions on glyph matrices used for rendering frame in terminal
@ 2022-07-04 19:37 Gerd Möllmann
  2022-07-05  2:49 ` Po Lu
  2022-07-05  4:26 ` Akib Azmain Turja
  0 siblings, 2 replies; 6+ messages in thread
From: Gerd Möllmann @ 2022-07-04 19:37 UTC (permalink / raw)
  To: akib; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 2914 bytes --]


>> 
> 1. What's the purpose of the following in
> build_frame_matrix_from_leaf_window?  "frame_row->used[TEXT_AREA]" will
> always end up being equal to "window_matrix->matrix_w" after processing
> the right-most window of the row.

I don't understand.  What about the /matrix_x/ + matrix_w below?

> 
> --8<---------------cut here---------------start------------->8---
>       /* Set number of used glyphs in the frame matrix.  Since we fill
>          up with spaces, and visit leaf windows from left to right it
>          can be done simply.  */
>       frame_row->used[TEXT_AREA]
>         = window_matrix->matrix_x + window_matrix->matrix_w;
> --8<---------------cut here---------------end--------------->8---
> 
> 
> 2. From the documentation of make-terminal-frame:
> 
> > Note that changing the size of one terminal frame automatically
> > affects all frames on the same terminal device.
> 
> 
> But why?  Do they share glyph matrices, since only one of them is
> visible at a single time?

How else should other frames behave?  Leave a "hole" on the terminal where nothing is displayed when the TTY window is made larger?  And what if the terminal is made smaller?

> 
> 
> 3. Why clear the desired matrix in build_frame_matrix?  As I understand,
> that would clear the glyph matrices of windows the frame, because window
> desired matrix shares memory with frame desired matrix, and its seems
> like build_frame_matrix is called after window desired matrices are
> built.
> 
> --8<---------------cut here---------------start------------->8---
>   /* Clear all rows in the frame matrix covered by window matrices.
>      Menu bar lines are not covered by windows.  */
>   for (i = FRAME_TOP_MARGIN (f); i < f->desired_matrix->nrows; ++i)
>     clear_glyph_row (MATRIX_ROW (f->desired_matrix, i));
> --8<---------------cut here---------------end--------------->8---

In the TTY case, the glyph memory (struct glyph) for desired window matrices is sub-allocated from the glyph memory that is allocated for the frame.  The glyph_row structures on the other hand are different between windows and frame.  Clear_glyph_row doesn't affect the glyph memory, only the glyh_rows.

> 
> 
> 4. And one more question: why don't Emacs is use the window feature of
> ncurses despite depending on it?  Is it inefficient or lack of any
> feature?
> 

The reasons I can think of are

- ncurses is considerably younger than Emacs
- Its predecessor 'curses' (from BSD, IIRC) wasn't available everywhere (think VMS, MS-DOS, maybe others), when that part of the code was written.  I would guess that might have been around 1985.  What would that be - Emacs 16 :-).

Maybe there are also other technical reasons that make a rewrite with ncurses impossible, I don'T know.

(And there's of course always the consideration of why rewrite something that works.)




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Questions on glyph matrices used for rendering frame in terminal
  2022-07-04 19:37 Questions on glyph matrices used for rendering frame in terminal Gerd Möllmann
@ 2022-07-05  2:49 ` Po Lu
  2022-07-05  4:26 ` Akib Azmain Turja
  1 sibling, 0 replies; 6+ messages in thread
From: Po Lu @ 2022-07-05  2:49 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: akib, emacs-devel

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


> The reasons I can think of are
>
> - ncurses is considerably younger than Emacs
> - Its predecessor 'curses' (from BSD, IIRC) wasn't available
> everywhere (think VMS, MS-DOS, maybe others), when that part of the
> code was written.  I would guess that might have been around 1985.
> What would that be - Emacs 16 :-).
>
> Maybe there are also other technical reasons that make a rewrite with
> ncurses impossible, I don'T know.
>
> (And there's of course always the consideration of why rewrite
> something that works.)

And that Emacs doesn't depend on ncurses even on Unix.  AFAIK regular
BSD curses is used on AIX.

The text terminal display code also has to work on MS-DOS and
MS-Windows, in both cases without even using tputs/tparam/etc.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Questions on glyph matrices used for rendering frame in terminal
  2022-07-04 19:37 Questions on glyph matrices used for rendering frame in terminal Gerd Möllmann
  2022-07-05  2:49 ` Po Lu
@ 2022-07-05  4:26 ` Akib Azmain Turja
  2022-07-05  6:24   ` Gerd Möllmann
  1 sibling, 1 reply; 6+ messages in thread
From: Akib Azmain Turja @ 2022-07-05  4:26 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 3700 bytes --]

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

>>> 
>> 1. What's the purpose of the following in
>> build_frame_matrix_from_leaf_window?  "frame_row->used[TEXT_AREA]" will
>> always end up being equal to "window_matrix->matrix_w" after processing
>> the right-most window of the row.
>
> I don't understand.  What about the /matrix_x/ + matrix_w below?

Oh sorry, I meant "it will end up being equal to
*frame_matrix->matrix_w*".

>
>> 
>> --8<---------------cut here---------------start------------->8---
>>       /* Set number of used glyphs in the frame matrix.  Since we fill
>>          up with spaces, and visit leaf windows from left to right it
>>          can be done simply.  */
>>       frame_row->used[TEXT_AREA]
>>         = window_matrix->matrix_x + window_matrix->matrix_w;
>> --8<---------------cut here---------------end--------------->8---
>> 
>> 
>> 2. From the documentation of make-terminal-frame:
>> 
>> > Note that changing the size of one terminal frame automatically
>> > affects all frames on the same terminal device.
>> 
>> 
>> But why?  Do they share glyph matrices, since only one of them is
>> visible at a single time?
>
> How else should other frames behave?  Leave a "hole" on the terminal where nothing is displayed when the TTY window is made larger?  And what if the terminal is made smaller?

The documentation says that something will happen, but I don't know
since I have never tried to do that.

>
>> 
>> 
>> 3. Why clear the desired matrix in build_frame_matrix?  As I understand,
>> that would clear the glyph matrices of windows the frame, because window
>> desired matrix shares memory with frame desired matrix, and its seems
>> like build_frame_matrix is called after window desired matrices are
>> built.
>> 
>> --8<---------------cut here---------------start------------->8---
>>   /* Clear all rows in the frame matrix covered by window matrices.
>>      Menu bar lines are not covered by windows.  */
>>   for (i = FRAME_TOP_MARGIN (f); i < f->desired_matrix->nrows; ++i)
>>     clear_glyph_row (MATRIX_ROW (f->desired_matrix, i));
>> --8<---------------cut here---------------end--------------->8---
>
> In the TTY case, the glyph memory (struct glyph) for desired window matrices is sub-allocated from the glyph memory that is allocated for the frame.  The glyph_row structures on the other hand are different between windows and frame.  Clear_glyph_row doesn't affect the glyph memory, only the glyh_rows.

I can't understand.  What does that glyph memory contain?  Individual
glyphs or the glyph matrix?  If the glyph memory holds the glyph matrix,
then IIUC glyph row is a row of that glyph matrix, so why clearing that
doesn't affect the glyph matrix?

>
>> 
>> 
>> 4. And one more question: why don't Emacs is use the window feature of
>> ncurses despite depending on it?  Is it inefficient or lack of any
>> feature?
>> 
>
> The reasons I can think of are
>
> - ncurses is considerably younger than Emacs
> - Its predecessor 'curses' (from BSD, IIRC) wasn't available everywhere (think VMS, MS-DOS, maybe others), when that part of the code was written.  I would guess that might have been around 1985.  What would that be - Emacs 16 :-).
>
> Maybe there are also other technical reasons that make a rewrite with ncurses impossible, I don'T know.
>
> (And there's of course always the consideration of why rewrite something that works.)

No, I'm not saying to rewrite, just wanted to know.

>
>
>

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Questions on glyph matrices used for rendering frame in terminal
  2022-07-05  4:26 ` Akib Azmain Turja
@ 2022-07-05  6:24   ` Gerd Möllmann
  2022-07-05  9:03     ` Akib Azmain Turja
  0 siblings, 1 reply; 6+ messages in thread
From: Gerd Möllmann @ 2022-07-05  6:24 UTC (permalink / raw)
  To: Akib Azmain Turja; +Cc: emacs-devel


[-- Attachment #1.1: Type: text/plain, Size: 2173 bytes --]



> On 2022-07-05,, at 6:26 , Akib Azmain Turja <akib@disroot.org> wrote:
> 
> Gerd Möllmann <gerd.moellmann@gmail.com <mailto:gerd.moellmann@gmail.com>> writes:
> 
>>>> 
>>> 1. What's the purpose of the following in
>>> build_frame_matrix_from_leaf_window? "frame_row->used[TEXT_AREA]" will
>>> always end up being equal to "window_matrix->matrix_w" after processing
>>> the right-most window of the row.
>> 
>> I don't understand. What about the /matrix_x/ + matrix_w below?
> 
> Oh sorry, I meant "it will end up being equal to
> *frame_matrix->matrix_w*".

Probably.  I don't remember what I thought exactly when I wrote that code.  But, a few lines above what you mentioned there is

      /* Fill up the frame row with spaces up to the left margin of the
	 window row.  */
      fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);

In general, I prefer code that relies on what is known locally, instead of what is known more globally, so to speak.  (We have too much of that already in Emacs.)  Maybe that was the reason.

In this case, because of the fill_up..., we know locally that the frame row is filled up to matrix_x of the window, so...

>> In the TTY case, the glyph memory (struct glyph) for desired window matrices is sub-allocated from the glyph memory that is allocated for the frame. The glyph_row structures on the other hand are different between windows and frame. Clear_glyph_row doesn't affect the glyph memory, only the glyh_rows.
> 
> I can't understand. What does that glyph memory contain? Individual
> glyphs or the glyph matrix? If the glyph memory holds the glyph matrix,
> then IIUC glyph row is a row of that glyph matrix, so why clearing that
> doesn't affect the glyph matrix?

It does affect a struct glyph_matrix, indirectly, because a struct glyph_row used by it is memset to zeros.

But no struct glyph is modified by that.  Please take a look at clear_glyph_row.  Only bookkeeping information is cleared. The struct glyph_row points to struct glyphs, but the glyphs themselves are not changed.

Have you read dispextern.h?  There are some comments that might be helpful.



[-- Attachment #1.2: Type: text/html, Size: 4219 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Questions on glyph matrices used for rendering frame in terminal
  2022-07-05  6:24   ` Gerd Möllmann
@ 2022-07-05  9:03     ` Akib Azmain Turja
  0 siblings, 0 replies; 6+ messages in thread
From: Akib Azmain Turja @ 2022-07-05  9:03 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

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

>> On 2022-07-05,, at 6:26 , Akib Azmain Turja <akib@disroot.org> wrote:
>> 
>> Gerd Möllmann <gerd.moellmann@gmail.com <mailto:gerd.moellmann@gmail.com>> writes:
>> 
>>>>> 
>>>> 1. What's the purpose of the following in
>>>> build_frame_matrix_from_leaf_window? "frame_row->used[TEXT_AREA]" will
>>>> always end up being equal to "window_matrix->matrix_w" after processing
>>>> the right-most window of the row.
>>> 
>>> I don't understand. What about the /matrix_x/ + matrix_w below?
>> 
>> Oh sorry, I meant "it will end up being equal to
>> *frame_matrix->matrix_w*".
>
> Probably.  I don't remember what I thought exactly when I wrote that code.  But, a few lines above what you mentioned there is
>
>       /* Fill up the frame row with spaces up to the left margin of the
> 	 window row.  */
>       fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);
>
> In general, I prefer code that relies on what is known locally, instead of what is known more globally, so to speak.  (We have too much of that already in Emacs.)  Maybe that was the reason.
>
> In this case, because of the fill_up..., we know locally that the frame row is filled up to matrix_x of the window, so...
>
>>> In the TTY case, the glyph memory (struct glyph) for desired window matrices is sub-allocated from the glyph memory that is allocated for the frame. The glyph_row structures on the other hand are different between windows and frame. Clear_glyph_row doesn't affect the glyph memory, only the glyh_rows.
>> 
>> I can't understand. What does that glyph memory contain? Individual
>> glyphs or the glyph matrix? If the glyph memory holds the glyph matrix,
>> then IIUC glyph row is a row of that glyph matrix, so why clearing that
>> doesn't affect the glyph matrix?
>
> It does affect a struct glyph_matrix, indirectly, because a struct glyph_row used by it is memset to zeros.
>
> But no struct glyph is modified by that.  Please take a look at clear_glyph_row.  Only bookkeeping information is cleared. The struct glyph_row points to struct glyphs, but the glyphs themselves are not changed.
>
> Have you read dispextern.h?  There are some comments that might be helpful.
>
>

Now I get it.  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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-07-05  9:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-04 19:37 Questions on glyph matrices used for rendering frame in terminal Gerd Möllmann
2022-07-05  2:49 ` Po Lu
2022-07-05  4:26 ` Akib Azmain Turja
2022-07-05  6:24   ` Gerd Möllmann
2022-07-05  9:03     ` Akib Azmain Turja
  -- strict thread matches above, loose matches on Subject: below --
2022-07-04 17:26 Akib Azmain Turja

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).