all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#40278: 27.0.90; Flickering in Windows 10
@ 2020-03-29 16:11 Nicolas Bertolo
  2020-03-29 17:25 ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Nicolas Bertolo @ 2020-03-29 16:11 UTC (permalink / raw)
  To: 40278

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-29 16:11 bug#40278: 27.0.90; Flickering in Windows 10 Nicolas Bertolo
@ 2020-03-29 17:25 ` Eli Zaretskii
  2020-03-29 20:28   ` Nicolas Bértolo
  2020-03-29 20:58   ` Nicolas Bértolo
  0 siblings, 2 replies; 18+ messages in thread
From: Eli Zaretskii @ 2020-03-29 17:25 UTC (permalink / raw)
  To: Nicolas Bertolo; +Cc: 40278

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-29 17:25 ` Eli Zaretskii
@ 2020-03-29 20:28   ` Nicolas Bértolo
  2020-03-29 20:58   ` Nicolas Bértolo
  1 sibling, 0 replies; 18+ messages in thread
From: Nicolas Bértolo @ 2020-03-29 20:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 40278

> I don't see it.

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-29 17:25 ` Eli Zaretskii
  2020-03-29 20:28   ` Nicolas Bértolo
@ 2020-03-29 20:58   ` Nicolas Bértolo
  2020-03-30 14:06     ` Eli Zaretskii
  1 sibling, 1 reply; 18+ messages in thread
From: Nicolas Bértolo @ 2020-03-29 20:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 40278

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-29 20:58   ` Nicolas Bértolo
@ 2020-03-30 14:06     ` Eli Zaretskii
  2020-03-30 16:23       ` Noam Postavsky
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2020-03-30 14:06 UTC (permalink / raw)
  To: Nicolas Bértolo; +Cc: 40278

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-30 14:06     ` Eli Zaretskii
@ 2020-03-30 16:23       ` Noam Postavsky
  2020-03-30 16:40         ` Eli Zaretskii
  2020-03-31  8:48         ` martin rudalics
  0 siblings, 2 replies; 18+ messages in thread
From: Noam Postavsky @ 2020-03-30 16:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 40278, Nicolas Bértolo


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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-30 16:23       ` Noam Postavsky
@ 2020-03-30 16:40         ` Eli Zaretskii
  2020-03-30 17:15           ` Noam Postavsky
  2020-03-31  8:48         ` martin rudalics
  1 sibling, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2020-03-30 16:40 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 40278, nicolasbertolo

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-30 16:40         ` Eli Zaretskii
@ 2020-03-30 17:15           ` Noam Postavsky
  2020-03-30 18:29             ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Noam Postavsky @ 2020-03-30 17:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 40278, nicolasbertolo

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







^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-30 17:15           ` Noam Postavsky
@ 2020-03-30 18:29             ` Eli Zaretskii
  2020-03-30 19:21               ` Noam Postavsky
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2020-03-30 18:29 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 40278, nicolasbertolo

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-30 18:29             ` Eli Zaretskii
@ 2020-03-30 19:21               ` Noam Postavsky
  0 siblings, 0 replies; 18+ messages in thread
From: Noam Postavsky @ 2020-03-30 19:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 40278, nicolasbertolo

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.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-30 16:23       ` Noam Postavsky
  2020-03-30 16:40         ` Eli Zaretskii
@ 2020-03-31  8:48         ` martin rudalics
  2020-03-31 15:51           ` Nicolas Bértolo
  1 sibling, 1 reply; 18+ messages in thread
From: martin rudalics @ 2020-03-31  8:48 UTC (permalink / raw)
  To: Noam Postavsky, Eli Zaretskii; +Cc: 40278, Nicolas Bértolo

 > 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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-31  8:48         ` martin rudalics
@ 2020-03-31 15:51           ` Nicolas Bértolo
  2020-03-31 15:56             ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Nicolas Bértolo @ 2020-03-31 15:51 UTC (permalink / raw)
  To: martin rudalics; +Cc: 40278, Noam Postavsky

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-31 15:51           ` Nicolas Bértolo
@ 2020-03-31 15:56             ` Eli Zaretskii
  2020-03-31 16:10               ` Nicolas Bértolo
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2020-03-31 15:56 UTC (permalink / raw)
  To: Nicolas Bértolo; +Cc: 40278, npostavs

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-31 15:56             ` Eli Zaretskii
@ 2020-03-31 16:10               ` Nicolas Bértolo
  2020-04-01  6:36                 ` martin rudalics
  0 siblings, 1 reply; 18+ messages in thread
From: Nicolas Bértolo @ 2020-03-31 16:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 40278, Noam Postavsky

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-03-31 16:10               ` Nicolas Bértolo
@ 2020-04-01  6:36                 ` martin rudalics
  2020-04-01 14:25                   ` Noam Postavsky
  2020-04-01 20:39                   ` Nicolas Bértolo
  0 siblings, 2 replies; 18+ messages in thread
From: martin rudalics @ 2020-04-01  6:36 UTC (permalink / raw)
  To: Nicolas Bértolo, Eli Zaretskii; +Cc: 40278, Noam Postavsky





 > 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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-04-01  6:36                 ` martin rudalics
@ 2020-04-01 14:25                   ` Noam Postavsky
  2020-04-01 20:39                   ` Nicolas Bértolo
  1 sibling, 0 replies; 18+ messages in thread
From: Noam Postavsky @ 2020-04-01 14:25 UTC (permalink / raw)
  To: martin rudalics; +Cc: 40278, Nicolas Bértolo

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-04-01  6:36                 ` martin rudalics
  2020-04-01 14:25                   ` Noam Postavsky
@ 2020-04-01 20:39                   ` Nicolas Bértolo
  2022-05-16 11:52                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 18+ messages in thread
From: Nicolas Bértolo @ 2020-04-01 20:39 UTC (permalink / raw)
  To: martin rudalics; +Cc: 40278, Noam Postavsky

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





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#40278: 27.0.90; Flickering in Windows 10
  2020-04-01 20:39                   ` Nicolas Bértolo
@ 2022-05-16 11:52                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 18+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-16 11:52 UTC (permalink / raw)
  To: Nicolas Bértolo
  Cc: 40278, martin rudalics, Eli Zaretskii, Noam Postavsky

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?





^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-05-16 11:52 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-29 16:11 bug#40278: 27.0.90; Flickering in Windows 10 Nicolas Bertolo
2020-03-29 17:25 ` Eli Zaretskii
2020-03-29 20:28   ` Nicolas Bértolo
2020-03-29 20:58   ` Nicolas Bértolo
2020-03-30 14:06     ` Eli Zaretskii
2020-03-30 16:23       ` Noam Postavsky
2020-03-30 16:40         ` Eli Zaretskii
2020-03-30 17:15           ` Noam Postavsky
2020-03-30 18:29             ` Eli Zaretskii
2020-03-30 19:21               ` Noam Postavsky
2020-03-31  8:48         ` martin rudalics
2020-03-31 15:51           ` Nicolas Bértolo
2020-03-31 15:56             ` Eli Zaretskii
2020-03-31 16:10               ` Nicolas Bértolo
2020-04-01  6:36                 ` martin rudalics
2020-04-01 14:25                   ` Noam Postavsky
2020-04-01 20:39                   ` Nicolas Bértolo
2022-05-16 11:52                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.