Stipples and scroll optimizations

Stipples and scroll optimizations

[Po Lu]

When a glyph with a stipple background is displayed in the scrolled area
of the screen, the optimization in `scrolling_window' should not be
performed.  This is because stipples are "tiled" across the screen from
a constant origin, so the display of the stipple might not be correct
after it is copied to a different part of the frame.

That problem can easily be seen by setting the stipple of the default
face to `dimple1' and scrolling a little.

WDYT about such a change?

Re: Stipples and scroll optimizations

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Sun, 08 May 2022 15:22:34 +0800
> 
> When a glyph with a stipple background is displayed in the scrolled area
> of the screen, the optimization in `scrolling_window' should not be
> performed.  This is because stipples are "tiled" across the screen from
> a constant origin, so the display of the stipple might not be correct
> after it is copied to a different part of the frame.
> 
> That problem can easily be seen by setting the stipple of the default
> face to `dimple1' and scrolling a little.
> 
> WDYT about such a change?

If using scrolling_window in this case causes incorrect display, then
scrolling_window should be disabled.  But how would you know, in
update_window or its subroutines, that this is the case?

Re: Stipples and scroll optimizations

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> If using scrolling_window in this case causes incorrect display, then
> scrolling_window should be disabled.  But how would you know, in
> update_window or its subroutines, that this is the case?

We could make x_draw_glyph_string (and its counterparts) set a flag
inside the glyph row if a stipple is encountered, and then test that
inside scrolling_window.

Re: Stipples and scroll optimizations

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 08 May 2022 15:34:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If using scrolling_window in this case causes incorrect display, then
> > scrolling_window should be disabled.  But how would you know, in
> > update_window or its subroutines, that this is the case?
> 
> We could make x_draw_glyph_string (and its counterparts) set a flag
> inside the glyph row if a stipple is encountered, and then test that
> inside scrolling_window.

I think doing this is x_draw_glyph_string is too late, because that is
called after the test for applicability of scrolling_window was
already done, no?

Is the fact that some of the glyphs in a glyph-row use stipple easily
detectable by scanning the row's glyphs?  If so, update_window could
do that, just before it calls scrolling_window, and refrain from doing
so.

Alternatively, we could add a flag to the glyph_row structure, which
will be set the first time we see a face with stipple while producing
glyphs for the row, and then update_window could test that flag.

Re: Stipples and scroll optimizations

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I think doing this is x_draw_glyph_string is too late, because that is
> called after the test for applicability of scrolling_window was
> already done, no?

I meant to do the test beforehand, i.e. to the glyphs in the "previous"
glyph matrix, and to use its results when comparing that matrix to the
desired matrix in scrolling_window.

> Is the fact that some of the glyphs in a glyph-row use stipple easily
> detectable by scanning the row's glyphs?  If so, update_window could
> do that, just before it calls scrolling_window, and refrain from doing
> so.

No, whether or not a stipple is actually used is only known with
complete certainty to x_draw_glyph_string (and some of the functions
that it calls.)

Re: Stipples and scroll optimizations

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 08 May 2022 15:58:03 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think doing this is x_draw_glyph_string is too late, because that is
> > called after the test for applicability of scrolling_window was
> > already done, no?
> 
> I meant to do the test beforehand, i.e. to the glyphs in the "previous"
> glyph matrix, and to use its results when comparing that matrix to the
> desired matrix in scrolling_window.

Sorry, I don't understand: what is the "previous" glyph matrix, and
how can you use it for this test?

> > Is the fact that some of the glyphs in a glyph-row use stipple easily
> > detectable by scanning the row's glyphs?  If so, update_window could
> > do that, just before it calls scrolling_window, and refrain from doing
> > so.
> 
> No, whether or not a stipple is actually used is only known with
> complete certainty to x_draw_glyph_string (and some of the functions
> that it calls.)

Really?  I see that 'struct face' has a 'stipple' member, which is set
in realize_gui_face, and that happens when we realize the face, long
before x_draw_glyph_string is called.  And each glyph in a glyph_row
has a face_id member, which allows you to get at the corresponding
face structure.  Why cannot you use this to detect glyph_row's that
use stipples?  The only type of glyph whose stipple is ignored is the
cursor glyph, and that hardly matters for your purposes here, no?

Re: Stipples and scroll optimizations

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I don't understand: what is the "previous" glyph matrix, and
> how can you use it for this test?

I mean the glyph matrix representing what is currently on the glass, the
"current matrix".

> Really?  I see that 'struct face' has a 'stipple' member, which is set
> in realize_gui_face, and that happens when we realize the face, long
> before x_draw_glyph_string is called.  And each glyph in a glyph_row
> has a face_id member, which allows you to get at the corresponding
> face structure.  Why cannot you use this to detect glyph_row's that
> use stipples?  The only type of glyph whose stipple is ignored is the
> cursor glyph, and that hardly matters for your purposes here, no?

Whether or not a stipple is present usually depends on the `stippled_p'
flag, which is set in `x_set_glyph_string_gc'.  But for starters,
drawing an image glyph might change that flag, and an image might also
obscure the stipple entirely, in which case we don't want to inhibit the
scrolling optimization.

Re: Stipples and scroll optimizations

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 08 May 2022 17:20:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I don't understand: what is the "previous" glyph matrix, and
> > how can you use it for this test?
> 
> I mean the glyph matrix representing what is currently on the glass, the
> "current matrix".

But that can be different (even VERY different) from what _should_ be
on the glass.  We cannot rely on the current matrix for making such
decisions.

> > Really?  I see that 'struct face' has a 'stipple' member, which is set
> > in realize_gui_face, and that happens when we realize the face, long
> > before x_draw_glyph_string is called.  And each glyph in a glyph_row
> > has a face_id member, which allows you to get at the corresponding
> > face structure.  Why cannot you use this to detect glyph_row's that
> > use stipples?  The only type of glyph whose stipple is ignored is the
> > cursor glyph, and that hardly matters for your purposes here, no?
> 
> Whether or not a stipple is present usually depends on the `stippled_p'
> flag, which is set in `x_set_glyph_string_gc'.  But for starters,
> drawing an image glyph might change that flag, and an image might also
> obscure the stipple entirely, in which case we don't want to inhibit the
> scrolling optimization.

The logic is very simple (see x_set_glyph_string_gc) and depends only
the kind of "highlight" with which a glyph string should be
displayed.  All types of highlight except DRAW_CURSOR do the same when
the set the stippled_p flag of a glyph string: they all set it if the
face's 'stipple' member is non-zero.  Why cannot update_window do the
same?  If drawing the image glyph can change the flag (though I cannot
see where it does), then the same logic that depends on seeing image
glyphs in a glyph-row can be added to update_window.

So I still don't see what difficulties could there be in the method I
suggested, and what would be the advantages of doing what you wanted
after the first call to x_draw_glyph_string.

Please also note that update_window, and with it scrolling_window,
work _per_glyph_row_, whereas x_draw_glyph_string works
_per_glyph_string_, which is part of a glyph row.  So theoretically,
it could be that the first calls to x_draw_glyph_string don't see any
stippled face, and thus don't set the flag you want, so by the time
you realize that scrolling_window cannot be used it's too late.  (And
in general, scrolling_window is called _before_ we call
update_window_line, which is where x_draw_glyph_string is called.

Re: Stipples and scroll optimizations

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> But that can be different (even VERY different) from what _should_ be
> on the glass.  We cannot rely on the current matrix for making such
> decisions.

Yes, but the problem here is that we cannot copy what already _is_ on
the glass if there is a stipple.  So the contents of the desired matrix
are irrelevant for our purposes.

Re: Stipples and scroll optimizations

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> The logic is very simple (see x_set_glyph_string_gc) and depends only
> the kind of "highlight" with which a glyph string should be
> displayed.  All types of highlight except DRAW_CURSOR do the same when
> the set the stippled_p flag of a glyph string: they all set it if the
> face's 'stipple' member is non-zero.  Why cannot update_window do the
> same?  If drawing the image glyph can change the flag (though I cannot
> see where it does), then the same logic that depends on seeing image
> glyphs in a glyph-row can be added to update_window.

BTW, the scrolling optimization doesn't have to take the cursor into
account, since it is always cleared by gui_clear_cursor before a scroll
run actually happens on the glass, correct?

Thanks.

Re: Stipples and scroll optimizations

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 08 May 2022 18:59:52 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But that can be different (even VERY different) from what _should_ be
> > on the glass.  We cannot rely on the current matrix for making such
> > decisions.
> 
> Yes, but the problem here is that we cannot copy what already _is_ on
> the glass if there is a stipple.  So the contents of the desired matrix
> are irrelevant for our purposes.

Not necessarily true.  update_window does this:

      /* Try reusing part of the display by copying.  */
      if (row < end && !desired_matrix->no_scrolling_p)  <<<<<<<<<<<<<
	{
	  int rc = scrolling_window (w, (tab_line_row != NULL ? 1 : 0)
				     + (header_line_row != NULL ? 1 : 0));

If the desired matrix is irrelevant, why do we test the no_scrolling_p
flag on that matrix?

Anyway, feel free to do it your way, but I'd be very weary of using
flags from the current matrix if a safer method exists.

Re: Stipples and scroll optimizations

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Not necessarily true.  update_window does this:
>
>       /* Try reusing part of the display by copying.  */
>       if (row < end && !desired_matrix->no_scrolling_p)  <<<<<<<<<<<<<
> 	{
> 	  int rc = scrolling_window (w, (tab_line_row != NULL ? 1 : 0)
> 				     + (header_line_row != NULL ? 1 : 0));
>
> If the desired matrix is irrelevant, why do we test the no_scrolling_p
> flag on that matrix?

I'm not sure, but I cannot see how that can affect us here, since this
problem is only present when pixels containing stipplies that are
_already_ on the glass (before scrolling) are copied around during
scrolling.

Thanks.