Flicker on MS Windows

Flicker on MS Windows

[Po Lu]

Has anyone noticed that Emacs seems to flicker a lot on newer versions
of MS-Windows, such as Windows Vista and Windows 10?  I never used Emacs
much on Windows, but the flicker isn't noticable on Windows XP and 9X,
while scrolling from the top to the bottom of w32term.c in those newer
versions leaves chunks of text noticably missing, presumably between
w32_scroll_run and the rest of the window being displayed.  The menu bar
also constantly flickers, but I see that on Windows XP as well.

Thanks.

Re: Flicker on MS Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Sun, 06 Mar 2022 18:24:25 +0800
> 
> Has anyone noticed that Emacs seems to flicker a lot on newer versions
> of MS-Windows, such as Windows Vista and Windows 10?  I never used Emacs
> much on Windows, but the flicker isn't noticable on Windows XP and 9X,
> while scrolling from the top to the bottom of w32term.c in those newer
> versions leaves chunks of text noticably missing, presumably between
> w32_scroll_run and the rest of the window being displayed.  The menu bar
> also constantly flickers, but I see that on Windows XP as well.

With which version(s) of Emacs do you see this?

Re: Flicker on MS Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Date: Sun, 06 Mar 2022 18:24:25 +0800
>> 
>> Has anyone noticed that Emacs seems to flicker a lot on newer versions
>> of MS-Windows, such as Windows Vista and Windows 10?  I never used Emacs
>> much on Windows, but the flicker isn't noticable on Windows XP and 9X,
>> while scrolling from the top to the bottom of w32term.c in those newer
>> versions leaves chunks of text noticably missing, presumably between
>> w32_scroll_run and the rest of the window being displayed.  The menu bar
>> also constantly flickers, but I see that on Windows XP as well.

> With which version(s) of Emacs do you see this?

27.2, and also 28.0.91.

Re: Flicker on MS Windows

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Has anyone noticed that Emacs seems to flicker a lot on newer versions
> of MS-Windows, such as Windows Vista and Windows 10?  I never used Emacs
> much on Windows, but the flicker isn't noticable on Windows XP and 9X,
> while scrolling from the top to the bottom of w32term.c in those newer
> versions leaves chunks of text noticably missing, presumably between
> w32_scroll_run and the rest of the window being displayed.  The menu bar
> also constantly flickers, but I see that on Windows XP as well.

Emacs 27 & 28 are annoyingly flickering here as well (Windows 7 and up,
dunno about XP) compared to the same configuration under Lucid.

Re: Flicker on MS Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 06 Mar 2022 17:59:08 +0100
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Has anyone noticed that Emacs seems to flicker a lot on newer versions
> > of MS-Windows, such as Windows Vista and Windows 10?  I never used Emacs
> > much on Windows, but the flicker isn't noticable on Windows XP and 9X,
> > while scrolling from the top to the bottom of w32term.c in those newer
> > versions leaves chunks of text noticably missing, presumably between
> > w32_scroll_run and the rest of the window being displayed.  The menu bar
> > also constantly flickers, but I see that on Windows XP as well.
> 
> Emacs 27 & 28 are annoyingly flickering here as well (Windows 7 and up,
> dunno about XP) compared to the same configuration under Lucid.

Does the Lucid build have double-buffering enabled?

Re: Flicker on MS Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Emacs 27 & 28 are annoyingly flickering here as well (Windows 7 and up,
>> dunno about XP) compared to the same configuration under Lucid.
>
> Does the Lucid build have double-buffering enabled?

Now that you mention that, I seem to recall something about double
buffering that greatly reduced Lucid's flickering on the past.

How can I check that double buffering is enabled?

Re: Flicker on MS Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 06 Mar 2022 18:10:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Emacs 27 & 28 are annoyingly flickering here as well (Windows 7 and up,
> >> dunno about XP) compared to the same configuration under Lucid.
> >
> > Does the Lucid build have double-buffering enabled?
> 
> Now that you mention that, I seem to recall something about double
> buffering that greatly reduced Lucid's flickering on the past.
> 
> How can I check that double buffering is enabled?

It's in system-configuration-features: if XDBE is there, the build is
with double-buffering.

NEWS.26 tells you how to disable it, if you want to see its effect.

Re: Flicker on MS Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 06 Mar 2022 19:27:32 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Date: Sun, 06 Mar 2022 18:24:25 +0800
> >> 
> >> Has anyone noticed that Emacs seems to flicker a lot on newer versions
> >> of MS-Windows, such as Windows Vista and Windows 10?  I never used Emacs
> >> much on Windows, but the flicker isn't noticable on Windows XP and 9X,
> >> while scrolling from the top to the bottom of w32term.c in those newer
> >> versions leaves chunks of text noticably missing, presumably between
> >> w32_scroll_run and the rest of the window being displayed.  The menu bar
> >> also constantly flickers, but I see that on Windows XP as well.
> 
> > With which version(s) of Emacs do you see this?
> 
> 27.2, and also 28.0.91.

Also, how did "scroll from top to bottom" -- with what command(s)?
And how did you determine that this is related to w32_scroll_run, or
even that w32_scroll_run was called while you scrolled in this case?

Re: Flicker on MS Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Now that you mention that, I seem to recall something about double
>> buffering that greatly reduced Lucid's flickering on the past.
>> 
>> How can I check that double buffering is enabled?
>
> It's in system-configuration-features: if XDBE is there, the build is
> with double-buffering.

XDBE is in system-configuration-features.

> NEWS.26 tells you how to disable it, if you want to see its effect.

After evaluating

(modify-frame-parameters nil '((inhibit-double-buffering . t)))

and playing around for one minute, I see no apparent change, but IMO
this observation is too limited to be meaningful.

Re: Flicker on MS Windows

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Emacs 27 & 28 are annoyingly flickering here as well (Windows 7 and up,
>>> dunno about XP) compared to the same configuration under Lucid.
>>
>> Does the Lucid build have double-buffering enabled?
>
> Now that you mention that, I seem to recall something about double
> buffering that greatly reduced Lucid's flickering on the past.
>
> How can I check that double buffering is enabled?

Double buffering is enabled by default on all X11 builds, unless you
specify a configure-time option.  It's unrelated to the toolkit being
used (although GTK 3 has problems that cause a big black square to
appear for a moment when a frame is being resized, I'm looking into
that.)

Your X server must of course support the double buffering extension, but
most today do.

Re: Flicker on MS Windows

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> and playing around for one minute, I see no apparent change, but IMO
> this observation is too limited to be meaningful.

Yes, this flicker is too obvious, much more obvious than the X build
without double buffering.

Somehow it also seems to depend on the version of MS Windows being used.

Re: Flicker on MS Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Also, how did "scroll from top to bottom" -- with what command(s)?

I held down "C-v".

> And how did you determine that this is related to w32_scroll_run, or
> even that w32_scroll_run was called while you scrolled in this case?

I assumed that was the case, since commenting out that function makes
the part that doesn't flicker stop being updated when scrolling.

Thanks.

Re: Flicker on MS Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 07 Mar 2022 08:40:16 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Also, how did "scroll from top to bottom" -- with what command(s)?
> 
> I held down "C-v".

Then I'm afraid I cannot reproduce this.  I tried Emacs 27 on 2
different versions of Windows 10, and I don't see any abnormal
flickering when I lean on C-v.  The menu bar does flicker once in a
few seconds (and that is expected, given how eagerly we update our
menus)), but by that time Emacs scrolled many window-fulls.

Are you trying this with an optimized build or an unoptimized build?
An unoptimized build cannot keep up with the auto-repeat rate of the
keyboard, so the first scroll through the file could cause Emacs to
become stuck until you release the key.  But once you scroll the file
once (i.e. it is all fontified), even an unoptimized build behaves
reasonably, and I see no particular flickering, at least not on the
menu bar.  I certainly don't see any artifacts like left-over text --
that smells like some "optimization" of your video driver.  Try
disabling any advanced features of the display adapter you have there.

> > And how did you determine that this is related to w32_scroll_run, or
> > even that w32_scroll_run was called while you scrolled in this case?
> 
> I assumed that was the case, since commenting out that function makes
> the part that doesn't flicker stop being updated when scrolling.

Ah, you mean the call to w32_scroll_run in dispnew.c...  Does setting
w32-use-visible-system-caret non-nil help in any way?

Re: Flicker on MS Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Then I'm afraid I cannot reproduce this.  I tried Emacs 27 on 2
> different versions of Windows 10, and I don't see any abnormal
> flickering when I lean on C-v.  The menu bar does flicker once in a
> few seconds (and that is expected, given how eagerly we update our
> menus)), but by that time Emacs scrolled many window-fulls.

Hmm, that's weird.

> Are you trying this with an optimized build or an unoptimized build?
> An unoptimized build cannot keep up with the auto-repeat rate of the
> keyboard, so the first scroll through the file could cause Emacs to
> become stuck until you release the key.  But once you scroll the file
> once (i.e. it is all fontified), even an unoptimized build behaves
> reasonably, and I see no particular flickering, at least not on the
> menu bar.

It's an optimized build, with "-O2 -g3".

> I certainly don't see any artifacts like left-over text -- that smells
> like some "optimization" of your video driver.  Try disabling any
> advanced features of the display adapter you have there.

I meant to say that I guessed that w32_scroll_run is somehow involved by
commenting out w32_scroll_run and observing that old text was left-over
in places which would previously not flicker during scrolling.  (Because
copying the area that can be scrolled is faster than displaying the rest
of the screen contents, so the system displays the scrolled contents
before the rest can be drawn.)

> Ah, you mean the call to w32_scroll_run in dispnew.c...  Does setting
> w32-use-visible-system-caret non-nil help in any way?

It makes it flicker less, but the flicker is still noticable.

BTW, here's another way to reproduce some severe flicker on MS Windows:
just type "M-: (run-hooks 'xref-after-jump-hook) RET", and the tool bar
buttons, cursor and text start to flicker severely.  The tool bar
buttons flicker in a peculiar way: the background is displayed, but the
image itself flickers with interleaved bands of black.

It's also not affected by the setting of w32-use-visible-system-caret.

Thanks.

Re: Flicker on MS Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 07 Mar 2022 22:04:46 +0800
> 
> It's an optimized build, with "-O2 -g3".

And is this in "emacs -Q"?

> BTW, here's another way to reproduce some severe flicker on MS Windows:
> just type "M-: (run-hooks 'xref-after-jump-hook) RET", and the tool bar
> buttons, cursor and text start to flicker severely.  The tool bar
> buttons flicker in a peculiar way: the background is displayed, but the
> image itself flickers with interleaved bands of black.

I don't see any flickering here, after the above.  The window
recenters and I see a single line pulsed; that's all Moreover, Emacs
consumes exactly zero CPU cycles after evaluating that expression.

How long does it keep flickering after you evaluate the above form?
And what is the value of xref-after-jump-hook in your case?

> It's also not affected by the setting of w32-use-visible-system-caret.

It shouldn't be, AFAIU.

Re: Flicker on MS Windows

[Eli Zaretskii]

> Date: Mon, 07 Mar 2022 16:21:59 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > BTW, here's another way to reproduce some severe flicker on MS Windows:
> > just type "M-: (run-hooks 'xref-after-jump-hook) RET", and the tool bar
> > buttons, cursor and text start to flicker severely.  The tool bar
> > buttons flicker in a peculiar way: the background is displayed, but the
> > image itself flickers with interleaved bands of black.
> 
> I don't see any flickering here, after the above.  The window
> recenters and I see a single line pulsed; that's all.  Moreover, Emacs
> consumes exactly zero CPU cycles after evaluating that expression.

FTR: on Windows 10 I'm testing this in Emacs 27.2.

Re: Flicker on MS Windows

[Eli Zaretskii]

> Date: Mon, 07 Mar 2022 16:21:59 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > BTW, here's another way to reproduce some severe flicker on MS Windows:
> > just type "M-: (run-hooks 'xref-after-jump-hook) RET", and the tool bar
> > buttons, cursor and text start to flicker severely.  The tool bar
> > buttons flicker in a peculiar way: the background is displayed, but the
> > image itself flickers with interleaved bands of black.
> 
> I don't see any flickering here, after the above.  The window
> recenters and I see a single line pulsed; that's all Moreover, Emacs
> consumes exactly zero CPU cycles after evaluating that expression.

If I increase pulse-iterations to 1000 (from the default of 10), then
in an unoptimized build I see a rare and barely-visible flickering of
the tool bar images, as if they are redrawn.

However, I cannot find where this redrawing comes from.  Both xdisp.c
and dispnew.c do their jobs correctly, and the tool bar is never
actually redrawn on these levels.  If I put a breakpoint where
dispnew.c actually writes to the glass using the terminal-specific
write_glyphs method, as part of the update_frame call, that breakpoint
never breaks in all those 1000 iterations, not once.  Which means that
we correctly decide that the tool bar didn't change and does not need
to be redrawn.

So it sounds like it's some very low-level Windows-specific code,
perhaps triggered by messages we send to the GUI thread or something?
This is an area in Emacs about which I know very little.  Ideas
regarding what could cause this are welcome.

And again, it's barely perceptible here, even with this non-trivial
setup and a relatively slow Emacs.  I have no idea why it's so
prominent in your case (assuming it's the same issue that I see, which
is not certain, since what I see looks like redrawing of the images on
the tool-bar buttons).

Re: Flicker on MS Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 07 Mar 2022 16:21:59 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > BTW, here's another way to reproduce some severe flicker on MS Windows:
>> > just type "M-: (run-hooks 'xref-after-jump-hook) RET", and the tool bar
>> > buttons, cursor and text start to flicker severely.  The tool bar
>> > buttons flicker in a peculiar way: the background is displayed, but the
>> > image itself flickers with interleaved bands of black.
>> 
>> I don't see any flickering here, after the above.  The window
>> recenters and I see a single line pulsed; that's all.  Moreover, Emacs
>> consumes exactly zero CPU cycles after evaluating that expression.
>
> FTR: on Windows 10 I'm testing this in Emacs 27.2.

I tested on Emacs 28, but I see the same on 27.2, so that's odd.

Re: Flicker on MS Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> If I increase pulse-iterations to 1000 (from the default of 10), then
> in an unoptimized build I see a rare and barely-visible flickering of
> the tool bar images, as if they are redrawn.
>
> However, I cannot find where this redrawing comes from.  Both xdisp.c
> and dispnew.c do their jobs correctly, and the tool bar is never
> actually redrawn on these levels.  If I put a breakpoint where
> dispnew.c actually writes to the glass using the terminal-specific
> write_glyphs method, as part of the update_frame call, that breakpoint
> never breaks in all those 1000 iterations, not once.  Which means that
> we correctly decide that the tool bar didn't change and does not need
> to be redrawn.
>
> So it sounds like it's some very low-level Windows-specific code,
> perhaps triggered by messages we send to the GUI thread or something?
> This is an area in Emacs about which I know very little.  Ideas
> regarding what could cause this are welcome.
>
> And again, it's barely perceptible here, even with this non-trivial
> setup and a relatively slow Emacs.  I have no idea why it's so
> prominent in your case (assuming it's the same issue that I see, which
> is not certain, since what I see looks like redrawing of the images on
> the tool-bar buttons).

That is quite odd.  Unfortunately, I know next to nothing about Windows
programming, so I probably can't help.

But I wonder if implementing double buffering on MS-Windows would help
to alleviate the problem somewhat.

Thanks.

Re: Flicker on MS Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 08 Mar 2022 08:26:56 +0800
> 
> But I wonder if implementing double buffering on MS-Windows would help
> to alleviate the problem somewhat.

We can only reason about that once we understand where is the code
that causes the redrawing of the tool bar and the menu bar in these
scenarios.