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#16621: 24.3.50; Periodic timer + overlays = flickering near point Date: Mon, 03 Feb 2014 07:47:05 +0200 Message-ID: <83vbww3fza.fsf@gnu.org> References: <87r47m72ft.fsf@yandex.ru> <838utt4gff.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1391406492 16722 80.91.229.3 (3 Feb 2014 05:48:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Feb 2014 05:48:12 +0000 (UTC) Cc: 16621@debbugs.gnu.org, dgutov@yandex.ru To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 03 06:48:18 2014 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 1WACOI-00029P-8K for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Feb 2014 06:48:18 +0100 Original-Received: from localhost ([::1]:44049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WACOH-0005nq-QO for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Feb 2014 00:48:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WACO7-0005nj-RJ for bug-gnu-emacs@gnu.org; Mon, 03 Feb 2014 00:48:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WACO2-0004nn-VO for bug-gnu-emacs@gnu.org; Mon, 03 Feb 2014 00:48:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WACO2-0004nj-RI for bug-gnu-emacs@gnu.org; Mon, 03 Feb 2014 00:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WACO2-0004UW-73 for bug-gnu-emacs@gnu.org; Mon, 03 Feb 2014 00:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Feb 2014 05:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16621 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16621-submit@debbugs.gnu.org id=B16621.139140644317212 (code B ref 16621); Mon, 03 Feb 2014 05:48:02 +0000 Original-Received: (at 16621) by debbugs.gnu.org; 3 Feb 2014 05:47:23 +0000 Original-Received: from localhost ([127.0.0.1]:47112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WACNN-0004TX-UY for submit@debbugs.gnu.org; Mon, 03 Feb 2014 00:47:22 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:40120) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WACNJ-0004TN-SN for 16621@debbugs.gnu.org; Mon, 03 Feb 2014 00:47:19 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N0E00A00NWPIB00@mtaout29.012.net.il> for 16621@debbugs.gnu.org; Mon, 03 Feb 2014 07:49:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0E008BHO5P5U30@mtaout29.012.net.il>; Mon, 03 Feb 2014 07:49:02 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.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:84501 Archived-At: > From: Stefan Monnier > Cc: Dmitry Gutov , 16621@debbugs.gnu.org > Date: Sun, 02 Feb 2014 21:12:20 -0500 > > > But if there is an echo-area message, like the one displayed by > > isearch, this optimization is disabled, and we redisplay the echo > > area. > > I guess that could be counted as a bug. Maybe, maybe not: remember all the stuff with restoring previous echo area message and its clearing. And good luck unlocking the logic that implements that. E.g., this (relevant to the issue you raised): /* Normally the message* functions will have already displayed and updated the echo area, but the frame may have been trashed, or the update may have been preempted, so display the echo area again here. Checking message_cleared_p captures the case that the echo area should be cleared. */ if ((!NILP (echo_area_buffer[0]) && !display_last_displayed_message_p) || (!NILP (echo_area_buffer[1]) && display_last_displayed_message_p) || (message_cleared_p && minibuf_level == 0 /* If the mini-window is currently selected, this means the echo-area doesn't show through. */ && !MINI_WINDOW_P (XWINDOW (selected_window)))) { int window_height_changed_p = echo_area_display (0); if (message_cleared_p) update_miniwindow_p = true; must_finish = 1; /* If we don't display the current message, don't clear the message_cleared_p flag, because, if we did, we wouldn't clear the echo area in the next redisplay which doesn't preserve the echo area. */ if (!display_last_displayed_message_p) message_cleared_p = 0; See also redisplay_preserve_echo_area. In any case, I'm not sure that even if we somehow succeed in optimizing echo-area display, it would solve the problem with flickering. There are any number of reasons why Emacs could decide it needs to call update_frame at the end of a redisplay cycle; the conditions needed to avoid that are quite a few and difficult to satisfy, unless nothing, absolutely nothing happens since the last redisplay. IMO, we should look in a different area of the code. Specifically, any time we call update_frame, the cursor will be redrawn. Therefore, if we want to make such frequent redisplays less visually annoying, we need to analyze why the GUI cursor needs to be redrawn every time a frame is updated. This requires at least some X expert to see what are the conditions that require the cursor to be redrawn; to my non-expert opinion, if we didn't update anything in the vicinity of the cursor, there should be no need to redraw it. We don't move the cursor to where we write glyphs, like we do on a TTY, do we?