[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Excessive redisplay from lots of process output
From: |
Po Lu |
Subject: |
Re: Excessive redisplay from lots of process output |
Date: |
Sat, 25 Feb 2023 17:43:40 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
> 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:
XFlush (called by flush_frame) is the function which avoids doing
anything if nothing on the display has changed, as it makes no requests
itself. Calling flush_frame after a redisplay which does nothing is
harmless; all the OP is experiencing tells us is that XFlush is not to
blame, but most likely some other X protocol request calling _XReply.
> Where do we call _XReply and for what purpose? I don't see it in our
> sources anywhere.
_XReply is the function called with Xlib whenever you make an X protocol
request that has a reply, such as XGetWindowProperty:
dpyinfo = FRAME_DISPLAY_INFO (f);
if (XGetWindowProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
dpyinfo->Xatom_wm_state, 0, 2, False,
AnyPropertyType, &type, &format, &nitems,
&bytes_after, &data) != Success)
return;
if (!data || nitems != 2 || format != 32)
{
This is expensive because it involves sending a request to the X server
and waiting for a response, which easily takes hundereds of ms over a
slow network connection.
Fortunately, Emacs 29 should not call XSync as much as Emacs 28 did.
Which is why I asked Spencer to try it out.
- Re: Excessive redisplay from lots of process output, (continued)
- 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, 2023/02/25
- Re: Excessive redisplay from lots of process output,
Po Lu <=