GNU bug report logs - #40278
Flickering in Windows 10 (not double buffered)

Previous Next

To reply to this bug, email your comments to 40278 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Bertolo <nicolasbertolo <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 27.0.90; Flickering in Windows 10
Date: Sun, 29 Mar 2020 13:11:20 -0300

[Message part 1 (text/html, inline)]

Message #8 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Bertolo <nicolasbertolo <at> gmail.com>
Cc: 40278 <at> debbugs.gnu.org
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Sun, 29 Mar 2020 20:25:30 +0300

> Date: Sun, 29 Mar 2020 13:11:20 -0300
> From: Nicolas Bertolo <nicolasbertolo <at> gmail.com>
> Bcc: <nicolasbertolo <at> gmail.com>
> 
> 1) Open a long C++ file.
> 
> 2) Run (setq mouse-wheel-scroll-amount '(1)).
> 
> 3) Mouse the mouse whell up and down fast.
> 
> 4) Pay attention to the part of the screen that should show new content.
> 
> Sometimes it will flicker a few time before stabilizing.

I don't see it.

Message #11 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Sun, 29 Mar 2020 17:28:10 -0300

> I don't see it.

I'll try to debug my configuration to see what causes it to flicker more.

Message #14 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Sun, 29 Mar 2020 17:58:51 -0300

> I don't see it.

I have found that creating a child frame causes it to flicker a lot more.
Here is a video that shows what happens https://youtu.be/BsUqPpyAvVQ

To reproduce it:
1) Start runemacs -Q
2) Open a big C/C++ file (I used dispextern.h from emacs)
3) Run this code to create the child frame (in the scratch buffer)

(defun open-test ()
  (display-buffer-in-child-frame (get-buffer-create "test child-frame")
                   '((child-frame-parameters . ((width . 20)
                                                            (height . 10)
                                                            (top . 200)
                                                            (left . 100))))))
4) In the C/C++ buffer eval (open-test)
5) Scroll with the mouse wheel up and down.

I don't know if this is the same bug or if it's related.

El dom., 29 mar. 2020 a las 14:25, Eli Zaretskii (<eliz <at> gnu.org>) escribió:
>
> > Date: Sun, 29 Mar 2020 13:11:20 -0300
> > From: Nicolas Bertolo <nicolasbertolo <at> gmail.com>
> > Bcc: <nicolasbertolo <at> gmail.com>
> >
> > 1) Open a long C++ file.
> >
> > 2) Run (setq mouse-wheel-scroll-amount '(1)).
> >
> > 3) Mouse the mouse whell up and down fast.
> >
> > 4) Pay attention to the part of the screen that should show new content.
> >
> > Sometimes it will flicker a few time before stabilizing.
>
> I don't see it.

Message #17 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: 40278 <at> debbugs.gnu.org
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Mon, 30 Mar 2020 17:06:58 +0300

> From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
> Date: Sun, 29 Mar 2020 17:58:51 -0300
> Cc: 40278 <at> debbugs.gnu.org
> 
> > I don't see it.
> 
> I have found that creating a child frame causes it to flicker a lot more.
> Here is a video that shows what happens https://youtu.be/BsUqPpyAvVQ
> 
> To reproduce it:
> 1) Start runemacs -Q
> 2) Open a big C/C++ file (I used dispextern.h from emacs)
> 3) Run this code to create the child frame (in the scratch buffer)
> 
> (defun open-test ()
>   (display-buffer-in-child-frame (get-buffer-create "test child-frame")
>                    '((child-frame-parameters . ((width . 20)
>                                                             (height . 10)
>                                                             (top . 200)
>                                                             (left . 100))))))
> 4) In the C/C++ buffer eval (open-test)
> 5) Scroll with the mouse wheel up and down.

It doesn't flicker here, sorry.

Does anyone else see this?

Message #20 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org,
 Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Mon, 30 Mar 2020 12:23:42 -0400

>> To reproduce it:
>> 1) Start runemacs -Q
>> 2) Open a big C/C++ file (I used dispextern.h from emacs)
>> 3) Run this code to create the child frame (in the scratch buffer)
>> 
>> (defun open-test ()
>>   (display-buffer-in-child-frame (get-buffer-create "test child-frame")
>>                    '((child-frame-parameters . ((width . 20)
>>                                                             (height . 10)
>>                                                             (top . 200)
>>                                                             (left . 100))))))
>> 4) In the C/C++ buffer eval (open-test)
>> 5) Scroll with the mouse wheel up and down.
>
> It doesn't flicker here, sorry.
>
> Does anyone else see this?

I can see it here, especially on scroll towards the beginning of the
file (Emacs is maxing out the CPU while doing this).  It kind of looks
like the rectangle beneath the child frame gets repainted separately
from the rest.

In GNU Emacs 27.0.90 (build 1, x86_64-w64-mingw32)
 of 2020-03-30 built on VHOST2
Repository revision: c6e0981b96eaa12c28b70c949ccd6e426c13df4d
Repository branch: emacs-27
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Home (v10.0.1909.18363.720)

Message #23 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 40278 <at> debbugs.gnu.org, nicolasbertolo <at> gmail.com
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Mon, 30 Mar 2020 19:40:00 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Nicolas Bértolo <nicolasbertolo <at> gmail.com>,
>   40278 <at> debbugs.gnu.org
> Date: Mon, 30 Mar 2020 12:23:42 -0400
> 
> I can see it here, especially on scroll towards the beginning of the
> file (Emacs is maxing out the CPU while doing this).

If redisplay cannot keep up, you could indeed see partially-redrawn
window.  But I didn't understand this was the problem, and it doesn't
sound like "flicker" to me.

> It kind of looks like the rectangle beneath the child frame gets
> repainted separately from the rest.

What do you mean by "beneath" in this context?

Message #26 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org, nicolasbertolo <at> gmail.com
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Mon, 30 Mar 2020 13:15:39 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Noam Postavsky <npostavs <at> gmail.com>
>> Cc: Nicolas Bértolo <nicolasbertolo <at> gmail.com>,
>>   40278 <at> debbugs.gnu.org
>> Date: Mon, 30 Mar 2020 12:23:42 -0400
>> 
>> I can see it here, especially on scroll towards the beginning of the
>> file (Emacs is maxing out the CPU while doing this).
>
> If redisplay cannot keep up, you could indeed see partially-redrawn
> window.  But I didn't understand this was the problem, and it doesn't
> sound like "flicker" to me.

The "flicker" part is that it looks like the window turns momentarily
completely blank before redrawing.

>> It kind of looks like the rectangle beneath the child frame gets
>> repainted separately from the rest.
>
> What do you mean by "beneath" in this context?

There's occasionally a rectangle which seems to repainted slower than
its surroundings.  That rectangle is lower down (closer to my desk than
the ceiling) on my monitor than the child frame.  Also, I guess the text
it momentarily contains was previously behind the child frame in terms
of z-order (although it's a bit hard to tell because the repainting is
still too fast to really anything).

Message #29 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 40278 <at> debbugs.gnu.org, nicolasbertolo <at> gmail.com
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Mon, 30 Mar 2020 21:29:26 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 40278 <at> debbugs.gnu.org,  nicolasbertolo <at> gmail.com
> Date: Mon, 30 Mar 2020 13:15:39 -0400
> 
> The "flicker" part is that it looks like the window turns momentarily
> completely blank before redrawing.

That could happen if there's nothing in common between the previous
and the new contents of the window.  Again, if redisplay cannot keep
up, this is entirely normal, and any flicker related to such situation
is something we cannot do anything about.

> > What do you mean by "beneath" in this context?
> 
> There's occasionally a rectangle which seems to repainted slower than
> its surroundings.  That rectangle is lower down (closer to my desk than
> the ceiling) on my monitor than the child frame.  Also, I guess the text
> it momentarily contains was previously behind the child frame in terms
> of z-order (although it's a bit hard to tell because the repainting is
> still too fast to really anything).

What are the dimensions of that rectangle?  Is its width identical to
that of the parent frame, or is it smaller?  If smaller, is the width
similar to that of the child frame or different?

Message #32 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org, nicolasbertolo <at> gmail.com
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Mon, 30 Mar 2020 15:21:42 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > What do you mean by "beneath" in this context?
>> 
>> There's occasionally a rectangle which seems to repainted slower than
>> its surroundings.  That rectangle is lower down (closer to my desk than
>> the ceiling) on my monitor than the child frame.  Also, I guess the text
>> it momentarily contains was previously behind the child frame in terms
>> of z-order (although it's a bit hard to tell because the repainting is
>> still too fast to really anything).
>
> What are the dimensions of that rectangle?  Is its width identical to
> that of the parent frame, or is it smaller?  If smaller, is the width
> similar to that of the child frame or different?

The width is similar (equal, as far as I can tell) to the child frame.

Message #35 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org,
 Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Tue, 31 Mar 2020 10:48:45 +0200

> I can see it here, especially on scroll towards the beginning of the
> file (Emacs is maxing out the CPU while doing this

It maxes out here as well but I do not need to display a child frame for
that purpose.  Simply scrolling through dispextern.h suffices.  Here it
typically pauses for about ten seconds without any flicker though.

> ).  It kind of looks
> like the rectangle beneath the child frame gets repainted separately
> from the rest.

I have no idea why this should be related to scrolling.  Does any of
these happen with a normal frame put on top of the window you scroll?

martin

Message #38 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 40278 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Tue, 31 Mar 2020 12:51:37 -0300

> I have no idea why this should be related to scrolling.  Does any of
> these happen with a normal frame put on top of the window you scroll?

I think it is not possible to input into a frame that is partially hidden (and
thus not focused) by others in Windows. The mouse wheel does nothing and
keyboard inputs go to the topmost window.

Message #41 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: 40278 <at> debbugs.gnu.org, rudalics <at> gmx.at, npostavs <at> gmail.com
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Tue, 31 Mar 2020 18:56:39 +0300

> From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
> Date: Tue, 31 Mar 2020 12:51:37 -0300
> Cc: Noam Postavsky <npostavs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 40278 <at> debbugs.gnu.org
> 
> > I have no idea why this should be related to scrolling.  Does any of
> > these happen with a normal frame put on top of the window you scroll?
> 
> I think it is not possible to input into a frame that is partially hidden (and
> thus not focused) by others in Windows. The mouse wheel does nothing and
> keyboard inputs go to the topmost window.

It's possible, but you need to turn on the "active window tracking"
feature.  There are tiny programs floating around that allow you to do
that.  With that feature turned on, focus follows the mouse, like on X
Window system on Unix.

Message #44 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Tue, 31 Mar 2020 13:10:01 -0300

> It's possible, but you need to turn on the "active window tracking"
> feature.  There are tiny programs floating around that allow you to do
> that.  With that feature turned on, focus follows the mouse, like on X
> Window system on Unix.

Thank you for the tip!

Here are my results:

Emacs frame partially covered by an Emacs frame: Nothing happens. Mouse input
does not seem to go anywhere.

Emacs frame partially covered by a Windows explorer window: Emacs scrolls
normally, that is, in my case there is some flickering. But nothing like what
happens with a child frame.

Message #47 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 40278 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Wed, 1 Apr 2020 08:36:15 +0200

> Emacs frame partially covered by an Emacs frame: Nothing happens. Mouse input
> does not seem to go anywhere.

Might be that here I'm using yet another program to handle that case.
'mouse-wheel-follow-mouse' should not be involved but please make sure
that it's t.

> Emacs frame partially covered by a Windows explorer window: Emacs scrolls
> normally, that is, in my case there is some flickering. But nothing like what
> happens with a child frame.

From what Noam described the flickering could be due to the tool bar.
What happens when you write

(defun open-test ()
  (display-buffer-in-child-frame
   (get-buffer-create "test child-frame")
   '((child-frame-parameters . ((tool-bar-lines . 0)
				(width . 20)
                                (height . 10)
                                (top . 200)
                                (left . 100))))))

instead?

martin

Message #50 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 40278 <at> debbugs.gnu.org,
 Nicolas Bértolo <nicolasbertolo <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Wed, 01 Apr 2020 10:25:16 -0400

>> Emacs frame partially covered by an Emacs frame: Nothing happens. Mouse input
>> does not seem to go anywhere.

Seems to work fine for me.  I see the "normal" flickering, no slow-paint
rectangle.

>> Emacs frame partially covered by a Windows explorer window: Emacs scrolls
>> normally, that is, in my case there is some flickering. But nothing like what
>> happens with a child frame.

Same here.

martin rudalics <rudalics <at> gmx.at> writes:

> What happens when you write
>
> (defun open-test ()
>   (display-buffer-in-child-frame
>    (get-buffer-create "test child-frame")
>    '((child-frame-parameters . ((tool-bar-lines . 0)
> 				(width . 20)
>                                 (height . 10)
>                                 (top . 200)
>                                 (left . 100))))))

Doesn't make a difference, I still see the slow-paint rectangle.

=======================

At any rate, if I've understood the responses from Eli, it sounds like
there isn't any bug here, just that we haven't implemented double
buffering for Windows.

Message #53 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 40278 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Wed, 1 Apr 2020 17:39:06 -0300

>  From what Noam described the flickering could be due to the tool bar.
> What happens when you write
>
> (defun open-test ()
>    (display-buffer-in-child-frame
>     (get-buffer-create "test child-frame")
>     '((child-frame-parameters . ((tool-bar-lines . 0)
>                                 (width . 20)
>                                  (height . 10)
>                                  (top . 200)
>                                  (left . 100))))))
>
> instead?

No difference here.

> At any rate, if I've understood the responses from Eli, it sounds like
> there isn't any bug here, just that we haven't implemented double
> buffering for Windows.

This may be the reason indeed.

Message #60 received at 40278 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: 40278 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 Eli Zaretskii <eliz <at> gnu.org>, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#40278: 27.0.90; Flickering in Windows 10
Date: Mon, 16 May 2022 19:52:52 +0800

Nicolas Bértolo <nicolasbertolo <at> gmail.com> writes:

>> At any rate, if I've understood the responses from Eli, it sounds like
>> there isn't any bug here, just that we haven't implemented double
>> buffering for Windows.
>
> This may be the reason indeed.

So now that double buffering is implemented for MS Windows, do you still
see the flicker?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.