From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: update_window: w->desired_matrix is a partial representation. Date: Sat, 19 Jan 2019 11:16:32 +0200 Message-ID: <83h8e5atxr.fsf@gnu.org> References: NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1547889329 25780 195.159.176.226 (19 Jan 2019 09:15:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 09:15:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Keith David Bershatsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 19 10:15:25 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkmip-0006ZW-Vj for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 10:15:24 +0100 Original-Received: from localhost ([127.0.0.1]:53291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkmkw-0006tI-SV for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 04:17:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkmkI-0006sz-LN for emacs-devel@gnu.org; Sat, 19 Jan 2019 04:16:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkmkI-00026r-AR; Sat, 19 Jan 2019 04:16:54 -0500 Original-Received: from [176.228.60.248] (port=3801 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gkmkH-0001Yo-TX; Sat, 19 Jan 2019 04:16:54 -0500 In-reply-to: (message from Keith David Bershatsky on Thu, 17 Jan 2019 10:08:40 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232475 Archived-At: > Date: Thu, 17 Jan 2019 10:08:40 -0800 > From: Keith David Bershatsky > Cc: emacs-devel@gnu.org > > 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.