Re: update_window: w->desired_matrix is a partial representation.

[Keith David Bershatsky]

Thank you, Eli, for reviewing and responding to this particular thread.

VPOS 6 of the desired_matrix is _not_ enabled_p.  Thus, update_window_line is 
not called on that particular VPOS.

The cache of fake cursors contains relevant coordinates (x, y, hpos, vpos), 
which are needed for erasing and/or redrawing.  Let us assume that before 
redisplay, VPOS 5 has a floating BAR_CURSOR (which uses the X and HPOS of the 
last glyph of the row as a sort of anchor to draw/erase it).

0.  My header-line format.
1.  12345⤸
2.  67890⤸
3.  12345⤸
4.  67890
5.     |
6.  Every good boy deserves fudge.
7.  Once upon a time there lived a ....

When the "!" gets inserted into VPOS 1 and pushes lines 6+ downwards, the 
floating BAR_CURSOR also gets pushed down.

0.  My header-line format.
1.  12!34⤸
2.  56789⤸
3.  01234⤸
4.  56789⤸
5.  0
6.     |
7.  Every good boy deserves fudge.
8.  Once upon a time there lived a ....

There may not necessarily be a need to remove the BAR_CURSOR at this time.  
However, the cached coordinates are now invalid for the floating BAR_CURSOR 
because Y and VPOS have changed.  When it comes time to remove the BAR_CURSOR 
at some point in the future, the attempted removal will fail because said 
removal uses outdated coordinates.

For all lines that get pushed downwards, the fake cursors may not need to be 
removed at this point in time.  However, the Y and VPOS of all fake cursors in 
the cache that have VPOS 6+ need to be updated.  And, the last row of the cache 
that was at the bottom of the screen may no longer exist because it was pushed 
down beyond the bottom of the screen -- so we need to delete that last row from 
the cache.

I have a working draft that uses the existing function update_text_area (within 
dispnew.c) to track changes to each VPOS, and does the following:

-  All cached fake cursors for the changed VPOS are deleted from the cache.

-  The portion of each row that remains the same, do not need the fake cursors 
to be redrawn (except wherever overlaps occur when rif->write_glyphs gets 
called) -- instead, just the cache of fake cursors gets updated for that 
section of the row that remains the same.

-  Subsequent to each call of rif->write_glyphs, the fake cursors get redrawn 
for the length of what got rewritten by rif->write_glyphs and the cache gets 
updated accordingly.

-  As to the relevant section from the end of the row to the x-limit that gets 
cleared with rif->clear_end_of_line, fake cursors are redrawn on just the 
portion that got erased -- the cache is updated for the entire length between 
the end of the row and the right window edge (assumes no right margin).

If the above-described plan of attack sounds prudent/efficient, then perhaps 
the appropriate place to update VPOS 6+ of the cache in this situation is 
wherever redisplay "scrolls the text on the glass directly"?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [01-17-2019 05:56:18] <17 Jan 2019 15:56:18 +0200>
> From: Eli Zaretskii <address@hidden>
> To: Keith David Bershatsky <address@hidden>
> CC: address@hidden
> Subject: Re: update_window:  w->desired_matrix is a partial representation.
> 
> * * * 
> >
> > ERRONEOUS EXPECTATION:  I expected VPOS 6 of w->desired_matrix to be the 
> > line containing a visible line number 6, _not_ the subsequent line that 
> > contains "Every good by deserves fudge."
> 
> When you examine glyph rows of a glyph matrix, pay attention to the
> enabled_p flag of each row: a row whose enabled_p flag is reset does
> not really reflect the desired contents of the screen, but some random
> garbage.
> 
> If you are saying that row whose VPOS is 6 has its enabled_p flag set,
> and its contents is not what eventually appears on the screen, then
> I'd need a precise recipe, preferably without source-level changes to
> the current code, to reproduce the situation.  In general, redisplay
> in this case can update the screen via a method that scrolls the text
> on the glass directly, so you might not see that if you are not
> looking in the right place.  But that's just a hunch.
> 
> More generally, I don't think a display feature that relies on the
> contents of the desired matrix is a good idea, because the desired
> matrix is a tool for the display engine to update the screen, and is
> not supposed to convey the entire contents of a window, nor even
> describe reliably what will be actually updated.  Why did you need to
> rely on the desired matrix for your feature?
> 
> > QUESTION #1:  From within update_window, is it possible to programmatically 
> > access the glyph_row containing the visible line number 6?
> 
> You can look at glyph_matrix->rows[6], but the result is reliable only
> if the enabled_p flag of that row is set.
> 
> > QUESTION #2:  From within update_window, is it possible to programmatically 
> > test to see whether VPOS 6 and all subsequent screen lines have been pushed 
> > downwards to make room for the new VPOS 5?
> 
> You'd need to compare with the current_matrix for that.  But why would
> you need to know a thing like that?  Your code shouldn't care how
> exactly the display engine decided to update the screen.