Re: Excessive redisplay from lots of process output

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 25 Feb 2023 07:10:24 +0800
> From: Po Lu <Luangruo@yahoo.com>
> 
> If the problem is still there in Emacs 29, please run Emacs under xscope, and tell which request(s) are being made.  Emacs should not make X requests when nothing on the display has actually changed.

The backtrace posted by Spencer tells us that Emacs called
redisplay_preserve_echo_area:

>#0  0x00007ffff4abc5c0 in XFlush () at /lib64/libX11.so.6
>#1  0x00000000004d23d6 in x_flush (f=<optimized out>) at xterm.c:250
>#2  0x00000000004d2416 in x_flip_and_flush (f=0xf956d0) at xterm.c:246
>#3  0x00000000004d2416 in x_flip_and_flush (f=0xf956d0) at xterm.c:1230
>#4  0x0000000000461374 in redisplay_preserve_echo_area (f=<optimized
>out>) at frame.h:1700
>#5  0x0000000000461374 in redisplay_preserve_echo_area
>(from_where=from_where@entry=12) at xdisp.c:16527
>#6  0x00000000005bee33 in wait_reading_process_output
>(time_limit=time_limit@entry=0, nsecs=nsecs@entry=0,
>read_kbd=read_kbd@entry=-1, do_display=true,
>wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0,
>just_wait_proc=just_wait_proc@entry=0) at process.c:5808
>#7  0x000000000050aea4 in read_char (end_time=0x0,
>used_mouse_menu=0x7fffffffda5b, kbp=<synthetic pointer>) at
>keyboard.c:3926

And redisplay_preserve_echo_area calls flush_frame unconditionally for
the selected frame:

  void
  redisplay_preserve_echo_area (int from_where)
  {
    redisplay_trace ("redisplay_preserve_echo_area (%d)\n", from_where);

    block_input ();
    specpdl_ref count = SPECPDL_INDEX ();
    record_unwind_protect_void (unwind_redisplay_preserve_echo_area);
    block_buffer_flips ();
    unblock_input ();

    if (!NILP (echo_area_buffer[1]))
      {
	/* We have a previously displayed message, but no current
	   message.  Redisplay the previous message.  */
	display_last_displayed_message_p = true;
	redisplay_internal ();
	display_last_displayed_message_p = false;
      }
    else
      redisplay_internal ();

    flush_frame (SELECTED_FRAME ());  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
    unbind_to (count, Qnil);
  }

How can we avoid this call to flush_frame "when nothing on the display
has actually changed"?  We don't have any mechanism for update_frame
and/or redisplay_internal to tell back whether anything was changed on
display.  There's a lot that _can_ change:

  . text-area of the windows
  . mode lines, header lines, and tab-lines
  . menu bar, tool bar, and tab bar
  . fringes
  . scroll bars
  . frame's title
  . new frames and windows, including tooltips

We currently don't have any indication for whether any of those have
changed.

Where do we call _XReply and for what purpose?  I don't see it in our
sources anywhere.