* Stipples and scroll optimizations [not found] <87a6bs5w05.fsf.ref@yahoo.com> @ 2022-05-08 7:22 ` Po Lu 2022-05-08 7:30 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Po Lu @ 2022-05-08 7:22 UTC (permalink / raw) To: emacs-devel 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 7:22 ` Stipples and scroll optimizations Po Lu @ 2022-05-08 7:30 ` Eli Zaretskii 2022-05-08 7:34 ` Po Lu 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2022-05-08 7:30 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 7:30 ` Eli Zaretskii @ 2022-05-08 7:34 ` Po Lu 2022-05-08 7:40 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Po Lu @ 2022-05-08 7:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 7:34 ` Po Lu @ 2022-05-08 7:40 ` Eli Zaretskii 2022-05-08 7:58 ` Po Lu 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2022-05-08 7:40 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 7:40 ` Eli Zaretskii @ 2022-05-08 7:58 ` Po Lu 2022-05-08 9:06 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Po Lu @ 2022-05-08 7:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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.) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 7:58 ` Po Lu @ 2022-05-08 9:06 ` Eli Zaretskii 2022-05-08 9:20 ` Po Lu 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2022-05-08 9:06 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 9:06 ` Eli Zaretskii @ 2022-05-08 9:20 ` Po Lu 2022-05-08 10:46 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Po Lu @ 2022-05-08 9:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 9:20 ` Po Lu @ 2022-05-08 10:46 ` Eli Zaretskii 2022-05-08 10:59 ` Po Lu 2022-05-08 11:07 ` Po Lu 0 siblings, 2 replies; 12+ messages in thread From: Eli Zaretskii @ 2022-05-08 10:46 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 10:46 ` Eli Zaretskii @ 2022-05-08 10:59 ` Po Lu 2022-05-08 11:29 ` Eli Zaretskii 2022-05-08 11:07 ` Po Lu 1 sibling, 1 reply; 12+ messages in thread From: Po Lu @ 2022-05-08 10:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 10:59 ` Po Lu @ 2022-05-08 11:29 ` Eli Zaretskii 2022-05-08 11:46 ` Po Lu 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2022-05-08 11:29 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 11:29 ` Eli Zaretskii @ 2022-05-08 11:46 ` Po Lu 0 siblings, 0 replies; 12+ messages in thread From: Po Lu @ 2022-05-08 11:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stipples and scroll optimizations 2022-05-08 10:46 ` Eli Zaretskii 2022-05-08 10:59 ` Po Lu @ 2022-05-08 11:07 ` Po Lu 1 sibling, 0 replies; 12+ messages in thread From: Po Lu @ 2022-05-08 11:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-05-08 11:46 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87a6bs5w05.fsf.ref@yahoo.com> 2022-05-08 7:22 ` Stipples and scroll optimizations Po Lu 2022-05-08 7:30 ` Eli Zaretskii 2022-05-08 7:34 ` Po Lu 2022-05-08 7:40 ` Eli Zaretskii 2022-05-08 7:58 ` Po Lu 2022-05-08 9:06 ` Eli Zaretskii 2022-05-08 9:20 ` Po Lu 2022-05-08 10:46 ` Eli Zaretskii 2022-05-08 10:59 ` Po Lu 2022-05-08 11:29 ` Eli Zaretskii 2022-05-08 11:46 ` Po Lu 2022-05-08 11:07 ` Po Lu
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.