From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <Luangruo@yahoo.com>, Spencer Baugh <sbaugh@janestreet.com>
Cc: emacs-devel@gnu.org
Subject: Re: Excessive redisplay from lots of process output
Date: Sat, 25 Feb 2023 09:35:23 +0200 [thread overview]
Message-ID: <83ttzakxj8.fsf@gnu.org> (raw)
In-Reply-To: <619913E2-4062-4865-8351-5EADFA4DCC70@yahoo.com> (message from Po Lu on Sat, 25 Feb 2023 07:10:24 +0800)
> 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.
next prev parent reply other threads:[~2023-02-25 7:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 15:16 Excessive redisplay from lots of process output Spencer Baugh
2023-02-17 16:06 ` Eli Zaretskii
2023-02-17 16:41 ` Spencer Baugh
2023-02-24 19:14 ` Spencer Baugh
2023-02-24 19:34 ` Eli Zaretskii
2023-02-24 20:08 ` Spencer Baugh
2023-02-24 20:19 ` Eli Zaretskii
2023-02-24 20:33 ` Spencer Baugh
2023-02-24 20:51 ` Eli Zaretskii
2023-02-24 23:14 ` Po Lu
2023-02-24 23:10 ` Po Lu
2023-02-25 7:35 ` Eli Zaretskii [this message]
2023-02-25 9:43 ` Po Lu
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=83ttzakxj8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=Luangruo@yahoo.com \
--cc=emacs-devel@gnu.org \
--cc=sbaugh@janestreet.com \
/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.