[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Excessive redisplay from lots of process output
From: |
Eli Zaretskii |
Subject: |
Re: Excessive redisplay from lots of process output |
Date: |
Sat, 25 Feb 2023 09:35:23 +0200 |
> 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.
- Re: Excessive redisplay from lots of process output, (continued)
- Re: Excessive redisplay from lots of process output, Eli Zaretskii, 2023/02/17
- Re: Excessive redisplay from lots of process output, Spencer Baugh, 2023/02/17
- Re: Excessive redisplay from lots of process output, Spencer Baugh, 2023/02/24
- Re: Excessive redisplay from lots of process output, Eli Zaretskii, 2023/02/24
- Re: Excessive redisplay from lots of process output, Spencer Baugh, 2023/02/24
- Re: Excessive redisplay from lots of process output, Eli Zaretskii, 2023/02/24
- Re: Excessive redisplay from lots of process output, Spencer Baugh, 2023/02/24
- Re: Excessive redisplay from lots of process output, Eli Zaretskii, 2023/02/24
- Re: Excessive redisplay from lots of process output, Po Lu, 2023/02/24
- Re: Excessive redisplay from lots of process output, Po Lu, 2023/02/24
- Re: Excessive redisplay from lots of process output,
Eli Zaretskii <=
- Re: Excessive redisplay from lots of process output, Po Lu, 2023/02/25