bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

[Eli Zaretskii]

> 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?