bug#40278: 27.0.90; Flickering in Windows 10

bug#40278: 27.0.90; Flickering in Windows 10

[Nicolas Bertolo]

[-- Attachment #1: Type: text/html, Size: 7270 bytes --]

bug#40278: 27.0.90; Flickering in Windows 10

[Eli Zaretskii]

> Date: Sun, 29 Mar 2020 13:11:20 -0300
> From: Nicolas Bertolo <nicolasbertolo@gmail.com>
> Bcc: <nicolasbertolo@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.

bug#40278: 27.0.90; Flickering in Windows 10

[Nicolas Bértolo]

> I don't see it.

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

bug#40278: 27.0.90; Flickering in Windows 10

[Nicolas Bértolo]

> 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@gnu.org>) escribió:
>
> > Date: Sun, 29 Mar 2020 13:11:20 -0300
> > From: Nicolas Bertolo <nicolasbertolo@gmail.com>
> > Bcc: <nicolasbertolo@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.

bug#40278: 27.0.90; Flickering in Windows 10

[Eli Zaretskii]

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Sun, 29 Mar 2020 17:58:51 -0300
> Cc: 40278@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?

bug#40278: 27.0.90; Flickering in Windows 10

[Noam Postavsky]

>> 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)

bug#40278: 27.0.90; Flickering in Windows 10

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Nicolas Bértolo <nicolasbertolo@gmail.com>,
>   40278@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?

bug#40278: 27.0.90; Flickering in Windows 10

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@gmail.com>
>> Cc: Nicolas Bértolo <nicolasbertolo@gmail.com>,
>>   40278@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).

bug#40278: 27.0.90; Flickering in Windows 10

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: 40278@debbugs.gnu.org,  nicolasbertolo@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?

bug#40278: 27.0.90; Flickering in Windows 10

[Noam Postavsky]

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

bug#40278: 27.0.90; Flickering in Windows 10

[martin rudalics]

 > 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

bug#40278: 27.0.90; Flickering in Windows 10

[Nicolas Bértolo]

> 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.

bug#40278: 27.0.90; Flickering in Windows 10

[Eli Zaretskii]

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Tue, 31 Mar 2020 12:51:37 -0300
> Cc: Noam Postavsky <npostavs@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 40278@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.

bug#40278: 27.0.90; Flickering in Windows 10

[Nicolas Bértolo]

> 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.

bug#40278: 27.0.90; Flickering in Windows 10

[martin rudalics]

 > 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

bug#40278: 27.0.90; Flickering in Windows 10

[Noam Postavsky]

>> 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@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.

bug#40278: 27.0.90; Flickering in Windows 10

[Nicolas Bértolo]

>  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.

bug#40278: 27.0.90; Flickering in Windows 10

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Nicolas Bértolo <nicolasbertolo@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?