From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#10304: 24.0.92: display bug Date: Sun, 13 Jan 2013 20:08:32 +0200 Message-ID: <837gnhrm5b.fsf@gnu.org> References: <8762hihrj7.fsf@live.com> <8362gnhp9b.fsf@gnu.org> <8338yfamvk.fsf@gnu.org> <83wqvr8rci.fsf@gnu.org> <83ehhw8c15.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1358100537 26133 80.91.229.3 (13 Jan 2013 18:08:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Jan 2013 18:08:57 +0000 (UTC) Cc: 10304@debbugs.gnu.org, schwab@linux-m68k.org To: larsi@gnus.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 13 19:09:14 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TuRzd-0001NJ-JK for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jan 2013 19:09:13 +0100 Original-Received: from localhost ([::1]:41113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuRzN-0005Ak-9a for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jan 2013 13:08:57 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuRzE-0005Ac-Ed for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:08:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TuRz9-0006bB-Up for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:08:48 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuRz9-0006b6-RN for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:08:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TuRzS-0006TZ-Lz for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jan 2013 18:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10304 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10304-submit@debbugs.gnu.org id=B10304.135810051524859 (code B ref 10304); Sun, 13 Jan 2013 18:09:02 +0000 Original-Received: (at 10304) by debbugs.gnu.org; 13 Jan 2013 18:08:35 +0000 Original-Received: from localhost ([127.0.0.1]:58481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuRz0-0006St-Fe for submit@debbugs.gnu.org; Sun, 13 Jan 2013 13:08:35 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58399) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuRyx-0006Sf-Jc for 10304@debbugs.gnu.org; Sun, 13 Jan 2013 13:08:33 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGK00J00T05NI00@a-mtaout22.012.net.il> for 10304@debbugs.gnu.org; Sun, 13 Jan 2013 20:08:05 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGK00JH6T1HHD60@a-mtaout22.012.net.il>; Sun, 13 Jan 2013 20:08:05 +0200 (IST) In-reply-to: <83ehhw8c15.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:69722 Archived-At: > Date: Tue, 08 Jan 2013 07:43:50 +0200 > From: Eli Zaretskii > Cc: 10304@debbugs.gnu.org, schwab@linux-m68k.org > > I think I do understand. My suspicion is that we somehow fail to > realize that the screen estate formerly occupied by the image, and > everything that follows it, needs to be cleared in its entirety. On > the display engine level, the image takes just one "line" (called > "glyph row"), and perhaps we somehow don't realize that the height of > that "line" is large, and all of that needs to be cleared, not just > the number of text lines of "normal" height that will replace the > image on display. > > Thanks for the details, they confirm my suspicions. I now need to > find whodunit in the code... Please apply the patch below and run with it for a while. It makes the output of trace-redisplay more voluminous, but I don't see how else we could catch the problem. When the problem happens again, please post the results. Here's my analysis of what is involved; perhaps it will help you read the output and make some changes on the spot, if needed. The clearing of portions of display that no longer display anything is done as part of dispnew.c:update_window. It does that as part of the call to update_window_line, when the latter is passed a screen line (a.k.a. "row") that should be empty on display. Such empty lines have a single glyph (an "invented" blank character with charpos equal to point-max), whose sole purpose is to facilitate clearing of empty lines. These empty lines have the enabled_p flag set, which means they should be displayed. (update_window ignores lines whose enabled_p flag is reset, because these do not correspond to any part of the displayed text.) So, for us to fail to clear these empty lines, I see several possible reasons: . the logic in update_window somehow skips the loop that starts at line 3495 and which displays the empty lines past the end of the buffer; or . some redisplay optimization in xdisp.c decides that those parts of display do not need to be updated, and thus excludes them from the glyph matrix it constructs in w->desired_matrix, so that those lines are not updated by update_window; or . the function x_clear_end_of_line, which is called by update_window_line, or its terminal-specific back-end (e.g., xterm.c:x_clear_frame_area), which implements the meat of that function, somehow fail to clear the correct portion of the display. The patches below are designed to report enough info for us to be able to tell which of the above hypotheses, if any, is true. Btw, any idea when these problems started happening? Is it an old problem, or did it start to appear only recently? Thanks. Here are the patches: --- src/dispnew.c~0 2013-01-07 14:13:25.000000000 +0200 +++ src/dispnew.c 2013-01-13 14:22:21.549690800 +0200 @@ -3473,6 +3473,11 @@ while (row < end && !row->enabled_p) ++row; + TRACE ((stderr, + "update_window: first enabled: %d, last: %d, no_scrolling: %d\n", + row - desired_matrix->rows, end - desired_matrix->rows - 1, + desired_matrix->no_scrolling_p)); + /* Try reusing part of the display by copying. */ if (row < end && !desired_matrix->no_scrolling_p) { @@ -3481,6 +3486,7 @@ { /* All rows were found to be equal. */ paused_p = 0; + TRACE ((stderr, "scrolling_window found all rows equal\n")); goto set_cursor; } else if (rc > 0) @@ -3488,10 +3494,18 @@ /* We've scrolled the display. */ force_p = 1; changed_p = 1; + TRACE ((stderr, "scrolling_window scrolled the display\n")); } } /* Update the rest of the lines. */ + if (!(row < end && (force_p || !input_pending))) + { + TRACE ((stderr, + "NOT updating rest of lines; row = %d end = %d fp = %d ip = %d\n", + row - desired_matrix->rows, end - desired_matrix->rows - 1, + force_p, input_pending)); + } for (; row < end && (force_p || !input_pending); ++row) /* scrolling_window resets the enabled_p flag of the rows it reuses from current_matrix. */ @@ -3533,12 +3547,17 @@ tempted to optimize redisplay based on lines displayed in the first redisplay. */ if (MATRIX_ROW_BOTTOM_Y (row) >= yb) - for (i = vpos + 1; i < w->current_matrix->nrows - 1; ++i) - MATRIX_ROW (w->current_matrix, i)->enabled_p = 0; + { + TRACE ((stderr, "update_window marks rows %d - %d invalid\n", + vpos + 1, w->current_matrix->nrows - 2)); + for (i = vpos + 1; i < w->current_matrix->nrows - 1; ++i) + MATRIX_ROW (w->current_matrix, i)->enabled_p = 0; + } } /* Was display preempted? */ paused_p = row < end; + TRACE ((stderr, "update_window %spreempted\n", paused_p ? "" : "NOT ")); set_cursor: --- src/xdisp.c~0 2013-01-07 14:13:25.000000000 +0200 +++ src/xdisp.c 2013-01-13 16:14:15.697145600 +0200 @@ -25568,6 +25568,9 @@ from_y = WINDOW_TO_FRAME_PIXEL_Y (w, max (min_y, output_cursor.y)); to_y = WINDOW_TO_FRAME_PIXEL_Y (w, to_y); + TRACE ((stderr, "clear_frame_area: [%d - %d] [%d - %d]\n", + from_x, to_x, from_y, to_y)); + /* Prevent inadvertently clearing to end of the X window. */ if (to_x > from_x && to_y > from_y) {