From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16621@debbugs.gnu.org, dgutov@yandex.ru
Subject: bug#16621: 24.3.50; Periodic timer + overlays = flickering near point
Date: Mon, 03 Feb 2014 07:47:05 +0200 [thread overview]
Message-ID: <83vbww3fza.fsf@gnu.org> (raw)
In-Reply-To: <jwv61oxt06w.fsf-monnier+emacsbugs@gnu.org>
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, 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?
next prev parent reply other threads:[~2014-02-03 5:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-02 1:01 bug#16621: 24.3.50; Periodic timer + overlays = flickering near point Dmitry Gutov
2014-02-02 2:33 ` Stefan Monnier
2014-02-02 2:37 ` Dmitry Gutov
2014-02-02 16:39 ` Eli Zaretskii
2014-02-03 2:12 ` Stefan Monnier
2014-02-03 5:47 ` Eli Zaretskii [this message]
2014-02-03 13:41 ` Stefan Monnier
2014-02-03 16:14 ` Eli Zaretskii
2014-02-04 3:28 ` Stefan Monnier
2014-02-04 3:44 ` Eli Zaretskii
2014-02-04 2:34 ` Dmitry Gutov
2014-02-04 3:48 ` Eli Zaretskii
2014-02-04 6:17 ` Dmitry Gutov
2014-02-04 16:00 ` Eli Zaretskii
2014-02-04 22:08 ` Jan D.
2014-02-05 3:57 ` Eli Zaretskii
2014-02-05 6:02 ` Jan Djärv
2014-02-05 15:40 ` Eli Zaretskii
2014-02-05 13:46 ` Stefan Monnier
2014-02-05 15:59 ` Eli Zaretskii
2014-02-05 18:57 ` Stefan Monnier
2014-02-05 20:00 ` Eli Zaretskii
2014-02-05 21:46 ` Stefan Monnier
2014-02-06 5:56 ` Eli Zaretskii
2014-02-06 13:08 ` Stefan Monnier
2014-02-06 14:20 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83vbww3fza.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=16621@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.