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

[Eli Zaretskii]

> Date:  Thu, 17 Jan 2019 10:08:40 -0800
> From:  Keith David Bershatsky <address@hidden>
> Cc:  address@hidden
> 
> VPOS 6 of the desired_matrix is _not_ enabled_p.  Thus, update_window_line is 
> not called on that particular VPOS.

That means the contents of desired_matrix for this VPOS is not useful.

> The cache of fake cursors contains relevant coordinates (x, y, hpos, vpos), 
> which are needed for erasing and/or redrawing.

Why do you cache screen coordinates and not the buffer positions?  If
the screen contents around some cursor don't change, you don't need to
redraw the cursor, so you don't need the coordinates.  And if the
screen does change, more often than not the coordinates will be
inaccurate anyway, and need to be recomputed anew.  So why cache them?

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

This design assumes that update_window_line will be called for each
screen line where you have a cursor and whose contents change in some
way.  There's nothing in the display engine that makes sure this
assumption is true, since the display engine doesn't really know
anything about your fake cursors, does it?  For example, the display
engine could decide to use some optimization based on the buffer text,
which would invalidate your assumption.

Did you consider the alternative of calculating the screen coordinates
of the cursors like we do for the single "normal" cursor?  That is
done in set_cursor_from_row, which is called from display_line and
from several redisplay optimizations that avoid calling display_line.
You could call at the same places your function that recalculates the
coordinates of your cursors, if any, in that screen line, and then
store the calculated coordinates in the window structure, like we do
with the "normal" cursor.

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

See try_window_id.  Search for "Scroll the display" to see how it
bypasses update_window for the screen lines it scrolls.  Directly
above that you will find code that updates the cursor accordingly.

If you decide to keep your current design, you should augment it so
that any future changes that introduce additional bypasses, such as
the ones in try_window_id, will be supported by fake cursors with
minimum changes.