[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61667: 29.0.60; Failure to redisplay
From: |
Dmitry Gutov |
Subject: |
bug#61667: 29.0.60; Failure to redisplay |
Date: |
Sat, 25 Feb 2023 15:18:23 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
On 25/02/2023 09:21, Po Lu via Bug reports for GNU Emacs, the Swiss army
knife of text editors wrote:
Eli Zaretskii<eliz@gnu.org> writes:
Yes. Which means these X and GTK calls are not the direct culprit of
the delay.
What happens if you add an explicit call to XFlush afterwards?
If that makes it work, then the frame title delay is caused by some
slowness after the call is made.
An Xlib function will only place the request onto an output buffer,
which is normally flushed when it becomes full or the next time Xlib
decides to read input or wait for a reply from the X server. The
library also performs optimizations on requests inside the output
buffer, mostly those of the Poly* type. You have to call XFlush
manually after making a request if you really want it to be sent.
Alas, this doesn't fix the problem:
diff --git a/src/xfns.c b/src/xfns.c
index 528ae61ca32..803a692bfbf 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -2211,6 +2211,8 @@ x_set_name_internal (struct frame *f, Lisp_Object
name)
#ifdef USE_GTK
gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
SSDATA (encoded_name));
+ XFlush (FRAME_X_DISPLAY (f));
+
#else /* not USE_GTK */
XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), &text);
XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
@@ -2291,6 +2293,8 @@ x_set_name (struct frame *f, Lisp_Object name,
bool explicit)
name = f->title;
x_set_name_internal (f, name);
+
+ XFlush (FRAME_X_DISPLAY (f));
}
/* This function should be called when the user's lisp code has
@@ -2331,6 +2335,8 @@ x_set_title (struct frame *f, Lisp_Object name,
Lisp_Object old_name)
CHECK_STRING (name);
x_set_name_internal (f, name);
+
+ XFlush (FRAME_X_DISPLAY (f));
}
void
- bug#61667: 29.0.60; Failure to redisplay, (continued)
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay,
Dmitry Gutov <=
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/23
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Gregory Heytings, 2023/02/24
- bug#61667: 29.0.60; Failure to redisplay, Po Lu, 2023/02/24