bug#1867: Resizing window causes text flickering when using antialiased font on X

[Glenn Morris]

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?

[Jan D.]

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.

[Eli Zaretskii]

> Date: Wed, 05 Oct 2011 09:01:28 +0200
> From: "Jan D." <jan...@swipnet.se>
> Cc: Bo Lin <lbs...@gmail.com>, 18...@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?

[Jan Djärv]

Yes, but just the character under the cursor.

Jan D.

[Eli Zaretskii]

> Date: Wed, 05 Oct 2011 19:34:45 +0200
> From: Jan Djärv <jan...@swipnet.se>
> CC: r...@gnu.org, lbs...@gmail.com, 18...@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?

[Jan Djärv]

Hello.

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.

[Chong Yidong]

Eli Zaretskii <el...@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.

[Eli Zaretskii]

> From: Chong Yidong <c...@stupidchicken.com>
> Cc: "Jan D." <jan...@swipnet.se>, 18...@debbugs.gnu.org, lbs...@gmail.com
> Date: Wed, 05 Oct 2011 17:57:29 -0400

>
> Eli Zaretskii <el...@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?

[Jan D.]

Chong Yidong skrev 2011-10-05 23:57:
> Eli Zaretskii<el...@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.

[Jason Rumney]

Jan Djärv <jan...@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.

[Chong Yidong]

"Jan D." <jan...@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.

[Bo Lin]

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