GNU bug report logs -
#1867
Resizing window causes text flickering when using antialiased font on X
Previous Next
Reported by: Bo Lin <lbsmtp <at> gmail.com>
Date: Mon, 12 Jan 2009 10:20:03 UTC
Severity: normal
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1867 in the body.
You can then email your comments to 1867 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1867
; Package
emacs
.
(Mon, 12 Jan 2009 10:20:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Bo Lin <lbsmtp <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Mon, 12 Jan 2009 10:20:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
1. Choose a font FONTNAME which supports antialiasing. Confirm
antialiasing is turned on for FONTNAME in fontconfig:
$ fc-match -v FONTNAME |grep antialias
antialias: FcTrue(w)
2. emacs -q
3. M-: (set-face-attribute 'default nil :font "FONTNAME")
4. C-x 3 C-x 2
Now there are three windows. We'll name the upper-left window 1,
lower-left window 2, and the right window 3.
5. C-x b *scratch* RET C-x o C-x b *Messages* RET C-x o C-h i
6. Using mouse, quickly drag mode-line of window 1 up and down.
Observe how text in window 1 and 3 flicker as windows 1 and 2 are
resized. The main point is that window 3, though totally unaffected by
the resizing of windows 1 and 2 and showing a different buffer, is still
been constantly redrawn. This quite annoying, as even when the
mini-buffer window resizes, which happens quite frequently, will cause
the whole frame to flicker.
This flickering does *not* occur if using old X core fonts. To confirm,
start with `emacs -q -fn fixed' and repeat steps 4-6.
This flickering does *not* occur if using same XFT font but antialiasing
turned off. To confirm, turn antialiasing off for FONTNAME in
fontconfig, for example by putting the following in ~/.fonts.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font">
<edit name="antialias" mode="assign"><bool>false</bool></edit>
</match>
</fontconfig>
and again confirm by
$ fc-match -v FONTNAME |grep antialias
antialias: FcFalse(w)
then repeat steps 2-6.
This flickering does not occur in other XFT applications, such as gedit,
using same font with antialias enabled. Flickering also does not occur
in Emacs on Windows when using antialiased (cleartype) fonts.
In GNU Emacs 23.0.60.7 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
of 2009-01-12 on unicorn
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
configured using `configure '--prefix=/home/sadboy/apps/emacs/test' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=SCIM
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
global-auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
C-x 3 C-x 2 <help-echo> <help-echo> <help-echo> <down-mouse-1>
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
<mouse-movement> <help-echo> <mouse-movement> <help-echo>
<mouse-movement> <mouse-movement> <mouse-movement>
<help-echo> <mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <help-echo> <help-echo>
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
<help-echo> <mouse-movement> <help-echo> <mouse-movement>
<mouse-movement> <mouse-movement> <help-echo> <mouse-movement>
<help-echo> <mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<drag-mouse-1> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> C-u C-x = C-v C-l C-p C-n C-e
C-a C-e C-a C-x 0 C-x b * M e s s <tab> <return> C-x
o C-x 2 <help-echo> <down-mouse-1> <mouse-movement>
<help-echo> <mouse-movement> <mouse-movement> <mouse-movement>
<help-echo> <help-echo> <mouse-movement> <mouse-movement>
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
<help-echo> <mouse-movement> <mouse-movement> <help-echo>
<mouse-movement> <mouse-movement> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <mouse-movement> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <mouse-movement>
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
<help-echo> <help-echo> <help-echo> <mouse-movement>
<help-echo> <mouse-movement> <help-echo> <help-echo>
<help-echo> <help-echo> <mouse-movement> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<mouse-movement> <mouse-movement> <mouse-movement>
<help-echo> <help-echo> <help-echo> <mouse-movement>
<help-echo> <help-echo> <mouse-movement> <mouse-movement>
<help-echo> <mouse-movement> <help-echo> <help-echo>
<mouse-movement> <mouse-movement> <help-echo> <mouse-movement>
<help-echo> <help-echo> <help-echo> <mouse-movement>
<mouse-movement> <mouse-movement> <help-echo> <help-echo>
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
<help-echo> <mouse-movement> <help-echo> <mouse-movement>
<mouse-movement> <mouse-movement> <help-echo> <help-echo>
<mouse-movement> <mouse-movement> <help-echo> <help-echo>
<mouse-movement> <mouse-movement> <mouse-movement>
<drag-mouse-1> <help-echo> <help-echo> M-x r e p o
r <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Type "q" to restore this window, C-v to scroll help.
Char: E (69, #o105, #x45) point=77 of 798 (10%) column=0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Wed, 05 Oct 2011 01:14:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Bo Lin wrote:
> 1. Choose a font FONTNAME which supports antialiasing. Confirm
> antialiasing is turned on for FONTNAME in fontconfig:
>
> $ fc-match -v FONTNAME |grep antialias
> antialias: FcTrue(w)
>
> 2. emacs -q
> 3. M-: (set-face-attribute 'default nil :font "FONTNAME")
> 4. C-x 3 C-x 2
>
> Now there are three windows. We'll name the upper-left window 1,
> lower-left window 2, and the right window 3.
>
> 5. C-x b *scratch* RET C-x o C-x b *Messages* RET C-x o C-h i
> 6. Using mouse, quickly drag mode-line of window 1 up and down.
>
> Observe how text in window 1 and 3 flicker as windows 1 and 2 are
> resized. The main point is that window 3, though totally unaffected by
> the resizing of windows 1 and 2 and showing a different buffer, is still
> been constantly redrawn. This quite annoying, as even when the
> mini-buffer window resizes, which happens quite frequently, will cause
> the whole frame to flicker.
>
> This flickering does *not* occur if using old X core fonts. To confirm,
> start with `emacs -q -fn fixed' and repeat steps 4-6.
[...]
> In GNU Emacs 23.0.60.7 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
> of 2009-01-12 on unicorn
> Windowing system distributor `The X.Org Foundation', version 11.0.10502000
I don't seem to be able to reproduce this. Do you still see this with
the latest version of Emacs?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Wed, 05 Oct 2011 07:02:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris skrev 2011-10-05 03:13:
> Bo Lin wrote:
>
>> 1. Choose a font FONTNAME which supports antialiasing. Confirm
>> antialiasing is turned on for FONTNAME in fontconfig:
>>
>> $ fc-match -v FONTNAME |grep antialias
>> antialias: FcTrue(w)
>>
>> 2. emacs -q
>> 3. M-: (set-face-attribute 'default nil :font "FONTNAME")
>> 4. C-x 3 C-x 2
>>
>> Now there are three windows. We'll name the upper-left window 1,
>> lower-left window 2, and the right window 3.
>>
>> 5. C-x b *scratch* RET C-x o C-x b *Messages* RET C-x o C-h i
>> 6. Using mouse, quickly drag mode-line of window 1 up and down.
>>
>> Observe how text in window 1 and 3 flicker as windows 1 and 2 are
>> resized. The main point is that window 3, though totally unaffected by
>> the resizing of windows 1 and 2 and showing a different buffer, is still
>> been constantly redrawn. This quite annoying, as even when the
>> mini-buffer window resizes, which happens quite frequently, will cause
>> the whole frame to flicker.
>>
>> This flickering does *not* occur if using old X core fonts. To confirm,
>> start with `emacs -q -fn fixed' and repeat steps 4-6.
> [...]
>> In GNU Emacs 23.0.60.7 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
>> of 2009-01-12 on unicorn
>> Windowing system distributor `The X.Org Foundation', version 11.0.10502000
>
>
> I don't seem to be able to reproduce this. Do you still see this with
> the latest version of Emacs?
>
>
It is possible that this is not visible on faster systems. Antialiased
fonts requires erase of the old text then write of the new text from the
client (i.e. Emacs). This is slower than with core fonts where you call
XDrawImageString and the X server then does both erasing and writing.
The fact that unaffected windows get redrawn must have something to do
with the display engine. That may have been improved in later versions.
FWIW, I can't see any text flicker in the scenario above. However, the
hollow cursor in the non-selected windows do flicker which indicates
that there is some redrawing going on.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Wed, 05 Oct 2011 10:42:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 1867 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 05 Oct 2011 09:01:28 +0200
> From: "Jan D." <jan.h.d <at> swipnet.se>
> Cc: Bo Lin <lbsmtp <at> gmail.com>, 1867 <at> debbugs.gnu.org
>
> FWIW, I can't see any text flicker in the scenario above. However, the
> hollow cursor in the non-selected windows do flicker which indicates
> that there is some redrawing going on.
The way redisplay is written, _any_ change to dimensions of _any_
window sets a flag that will cause a thorough redisplay of all the
windows on all the visible frames. However, I'd expect that redisplay
of any window not affected by the resizing be limited to redrawing the
cursor.
So even when antialiased fonts are used, I wouldn't expect any
flickering, because Emacs should notice that the window didn't change
at all. Unless, that is, redrawing the cursor on X involves redrawing
parts of the window text. Does it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Wed, 05 Oct 2011 17:35:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii skrev 2011-10-05 12:41:
>> Date: Wed, 05 Oct 2011 09:01:28 +0200
>> From: "Jan D."<jan.h.d <at> swipnet.se>
>> Cc: Bo Lin<lbsmtp <at> gmail.com>, 1867 <at> debbugs.gnu.org
>>
>> FWIW, I can't see any text flicker in the scenario above. However, the
>> hollow cursor in the non-selected windows do flicker which indicates
>> that there is some redrawing going on.
>
> The way redisplay is written, _any_ change to dimensions of _any_
> window sets a flag that will cause a thorough redisplay of all the
> windows on all the visible frames. However, I'd expect that redisplay
> of any window not affected by the resizing be limited to redrawing the
> cursor.
>
> So even when antialiased fonts are used, I wouldn't expect any
> flickering, because Emacs should notice that the window didn't change
> at all. Unless, that is, redrawing the cursor on X involves redrawing
> parts of the window text. Does it?
Yes, but just the character under the cursor.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Wed, 05 Oct 2011 20:32:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 1867 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 05 Oct 2011 19:34:45 +0200
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: rgm <at> gnu.org, lbsmtp <at> gmail.com, 1867 <at> debbugs.gnu.org
>
> > So even when antialiased fonts are used, I wouldn't expect any
> > flickering, because Emacs should notice that the window didn't change
> > at all. Unless, that is, redrawing the cursor on X involves redrawing
> > parts of the window text. Does it?
>
> Yes, but just the character under the cursor.
And could redrawing a single character under the cursor cause
flickering with antialiased fonts?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Wed, 05 Oct 2011 21:17:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Hello.
5 okt 2011 kl. 22:29 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> Date: Wed, 05 Oct 2011 19:34:45 +0200
>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> CC: rgm <at> gnu.org, lbsmtp <at> gmail.com, 1867 <at> debbugs.gnu.org
>>
>>> So even when antialiased fonts are used, I wouldn't expect any
>>> flickering, because Emacs should notice that the window didn't change
>>> at all. Unless, that is, redrawing the cursor on X involves redrawing
>>> parts of the window text. Does it?
>>
>> Yes, but just the character under the cursor.
>
> And could redrawing a single character under the cursor cause
> flickering with antialiased fonts?
For that character it might happen if the clearing and writing is separated long enough in time. Depends on the speed of your machine.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Wed, 05 Oct 2011 21:58:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The way redisplay is written, _any_ change to dimensions of _any_
> window sets a flag that will cause a thorough redisplay of all the
> windows on all the visible frames. However, I'd expect that redisplay
> of any window not affected by the resizing be limited to redrawing the
> cursor.
Resizing a window redraws all windows on the same frame, even those
unaffected by the resizing.
The right way to fix flickering in Emacs is to implement double
buffering, which is not a trivial project.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Thu, 06 Oct 2011 05:34:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 1867 <at> debbugs.gnu.org (full text, mbox):
> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: "Jan D." <jan.h.d <at> swipnet.se>, 1867 <at> debbugs.gnu.org, lbsmtp <at> gmail.com
> Date: Wed, 05 Oct 2011 17:57:29 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > The way redisplay is written, _any_ change to dimensions of _any_
> > window sets a flag that will cause a thorough redisplay of all the
> > windows on all the visible frames. However, I'd expect that redisplay
> > of any window not affected by the resizing be limited to redrawing the
> > cursor.
>
> Resizing a window redraws all windows on the same frame, even those
> unaffected by the resizing.
What do you mean by "redraws"? It generates the full desired glyph
matrices for each window, but there's code in dispnew.c that compares
the desired matrix with the current matrix, and only redraws the parts
that changed. Are you saying that this optimization is disabled? Do
you actually see the xterm backend redrawing each and every window in
this use case?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Thu, 06 Oct 2011 06:06:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Chong Yidong skrev 2011-10-05 23:57:
> Eli Zaretskii<eliz <at> gnu.org> writes:
>
>> The way redisplay is written, _any_ change to dimensions of _any_
>> window sets a flag that will cause a thorough redisplay of all the
>> windows on all the visible frames. However, I'd expect that redisplay
>> of any window not affected by the resizing be limited to redrawing the
>> cursor.
>
> Resizing a window redraws all windows on the same frame, even those
> unaffected by the resizing.
But according to Eli, the redraw optimizations in Emacs display engine
should not actually redraw anything in unchanged windows.
According to the desciption window 3 is totally unchanged, but flickers
anyway.
But this was on 23.0.60. Many bugs has been fixed since.
>
> The right way to fix flickering in Emacs is to implement double
> buffering, which is not a trivial project.
If we are aiming for a general solution across all ports this is true.
A pure X solution might be easier if we use the double buffer extension.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Thu, 06 Oct 2011 14:18:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Jan Djärv <jan.h.d <at> swipnet.se> writes:
>> And could redrawing a single character under the cursor cause
>> flickering with antialiased fonts?
>
> For that character it might happen if the clearing and writing is
> separated long enough in time. Depends on the speed of your machine.
It used to happen on Windows, because the antialiasing around the
character overlaps with surrounding characters, causing much more than
just the character under the cursor to be redrawn. The fix was to
improve the clip region around the text that needs redrawing so that at
most only the immediately adjacent characters need redrawing, not the
whole line or in extreme cases, the whole frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Thu, 06 Oct 2011 15:07:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 1867 <at> debbugs.gnu.org (full text, mbox):
"Jan D." <jan.h.d <at> swipnet.se> writes:
>> The right way to fix flickering in Emacs is to implement double
>> buffering, which is not a trivial project.
>
> If we are aiming for a general solution across all ports this is true.
> A pure X solution might be easier if we use the double buffer
> extension.
I took a brief look into this some time ago. The DBE module is pretty
under-documented, and I wasn't able to find any code that uses it. GTK,
for instance, does its own double-buffering rather than using DBE.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1867
; Package
emacs
.
(Thu, 06 Oct 2011 19:44:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 1867 <at> debbugs.gnu.org (full text, mbox):
Hi Glenn,
This bug is no longer present as of Emacs 23.3, on the same machine.
Actually, I don't recall having this problem for a very long time,
since at least 23.1. I guess this bug can be closed.
Regards,
Bo
On Tue, Oct 4, 2011 at 9:13 PM, Glenn Morris <rgm <at> gnu.org> wrote:
> Bo Lin wrote:
>
>> 1. Choose a font FONTNAME which supports antialiasing. Confirm
>> antialiasing is turned on for FONTNAME in fontconfig:
>>
>> $ fc-match -v FONTNAME |grep antialias
>> antialias: FcTrue(w)
>>
>> 2. emacs -q
>> 3. M-: (set-face-attribute 'default nil :font "FONTNAME")
>> 4. C-x 3 C-x 2
>>
>> Now there are three windows. We'll name the upper-left window 1,
>> lower-left window 2, and the right window 3.
>>
>> 5. C-x b *scratch* RET C-x o C-x b *Messages* RET C-x o C-h i
>> 6. Using mouse, quickly drag mode-line of window 1 up and down.
>>
>> Observe how text in window 1 and 3 flicker as windows 1 and 2 are
>> resized. The main point is that window 3, though totally unaffected by
>> the resizing of windows 1 and 2 and showing a different buffer, is still
>> been constantly redrawn. This quite annoying, as even when the
>> mini-buffer window resizes, which happens quite frequently, will cause
>> the whole frame to flicker.
>>
>> This flickering does *not* occur if using old X core fonts. To confirm,
>> start with `emacs -q -fn fixed' and repeat steps 4-6.
> [...]
>> In GNU Emacs 23.0.60.7 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
>> of 2009-01-12 on unicorn
>> Windowing system distributor `The X.Org Foundation', version 11.0.10502000
>
>
> I don't seem to be able to reproduce this. Do you still see this with
> the latest version of Emacs?
>
bug closed, send any further explanations to
1867 <at> debbugs.gnu.org and Bo Lin <lbsmtp <at> gmail.com>
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Thu, 06 Oct 2011 20:39:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 04 Nov 2011 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.