[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: |
Sun, 26 Feb 2023 13:59:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
On 26/02/2023 08:44, Eli Zaretskii wrote:
Sorry, I'm still confused. Let me try to explain what I understand
and what confuses me.
There are two use cases where you see the problem:
. "emacs -Q", then type 'a' (which visits a file?)
. "emacs" with your configuration, then type "C-x b", which visits a
file
In both cases, you see a delay before the display is updated, right?
About 1 in 5-10 tries the delay is high enough to be noticeable
(200-300ms with -Q and up to 1-2 seconds with my config).
So what effect, if any, does the changing vs fixed frame title have on
each of these two use cases?
The delay (which is, physically, always present) becomes never nigh
enough to be noticeable.
Or, in simple terms, disappears.
And what effect does disabling
double-buffering have on each of these two cases?
Same effect: delay "disappears".
AFAIR, you originally said that when the title is not updated, the
problem disappears.
Yes.
Then you said that the problem does NOT disappear
when the title is fixed, but having the title change makes it easier
to realize that the delay exists.
I only said (or meant to say) that having the title change made it
easier to understand that there definitely *is* a problem. Because
otherwise I could attribute the delay to various sources of latency we
could experience: reading from disk (or network, whatever), triggering a
garbage collection, etc. But since the title changes, the buffer must
already be read and visited, and yet it's not displayed in the frame for
some time.
Now you are saying something else.
This is what confuses me: what is the effect of the changing frame
title on the above two cases?
Delay disappears.
- bug#61667: 29.0.60; Failure to redisplay, (continued)
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Gregory Heytings, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Gregory Heytings, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Gregory Heytings, 2023/02/25
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 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, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay,
Dmitry Gutov <=
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Eli Zaretskii, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Gregory Heytings, 2023/02/26
- bug#61667: 29.0.60; Failure to redisplay, Dmitry Gutov, 2023/02/26