GNU bug report logs - #34710
the mode line flicks on set-window-vscroll

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34710 in the body.
You can then email your comments to 34710 AT debbugs.gnu.org in the normal way.

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

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

From: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>
To: bug-gnu-emacs <at> gnu.org
Cc: 国広卓也 <tkk <at> misasa.okayama-u.ac.jp>
Subject: the mode line flicks on set-window-vscroll
Date: Sat, 2 Mar 2019 19:25:13 +0900

On Emacs-26.1.92 build for macOS, I see the mode line flicks when I
scroll-up using pixel-scroll-mode and mouse wheel.  The mode line does
not flick on scrolling-down.  I do not see this problem in
Emacs-26.1.92 build for Windows.

macOS$ /Downloads/emacs-26.1.92/nextstep/Emacs.app/Contents/MacOS/Emacs -Q
M-x pixel-scroll-mode
M-: (pixel-scroll-up 1) ; => the mode line flicks
M-: (pixel-scroll-down 1) ;=> no flick

I narrow down the problem and notice that following
two blocks response differently.

#+begin_src emacs-lisp
(dolist (vs (number-sequence 1 10))
  (set-window-vscroll nil vs t)
  (sit-for 0))
;; the mode line flicks
#+end_src

#+begin_src emacs-lisp
(dolist (vs (number-sequence 1 10))
  (set-window-vscroll nil vs t))
;; no flick
#+end_src

Do you have idea?

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

From: Alan Third <alan <at> idiocy.org>
To: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>
Cc: 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Sat, 2 Mar 2019 20:10:48 +0000

On Sat, Mar 02, 2019 at 07:25:13PM +0900, Tak Kunihiro wrote:
> On Emacs-26.1.92 build for macOS, I see the mode line flicks when I
> scroll-up using pixel-scroll-mode and mouse wheel.  The mode line does
> not flick on scrolling-down.  I do not see this problem in
> Emacs-26.1.92 build for Windows.
> 
> macOS$ /Downloads/emacs-26.1.92/nextstep/Emacs.app/Contents/MacOS/Emacs -Q
> M-x pixel-scroll-mode
> M-: (pixel-scroll-up 1) ; => the mode line flicks
> M-: (pixel-scroll-down 1) ;=> no flick
> 
> I narrow down the problem and notice that following
> two blocks response differently.
> 
> #+begin_src emacs-lisp
> (dolist (vs (number-sequence 1 10))
>   (set-window-vscroll nil vs t)
>   (sit-for 0))
> ;; the mode line flicks
> #+end_src
> 
> #+begin_src emacs-lisp
> (dolist (vs (number-sequence 1 10))
>   (set-window-vscroll nil vs t))
> ;; no flick
> #+end_src
> 
> Do you have idea?

I believe it’s a problem with running redisplay rapidly (sit-for) and
the way we’re drawing in NS. We end up with macOS demanding a screen
update, and Emacs unable to deliver due to there being another
redisplay coming up.

The patch attached to this discussion doesn’t have the problem:

https://lists.gnu.org/archive/html/emacs-devel/2019-02/msg00354.html

However Robert Pluim reported serious performance problems with it. I
haven’t been able to replicate them.

-- 
Alan Third

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

From: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>
To: Alan Third <alan <at> idiocy.org>
Cc: 国広卓也 <tkk <at> misasa.okayama-u.ac.jp>,
 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Sun, 3 Mar 2019 13:15:14 +0900

The patch solved the problem.

I also see that it takes more time to scroll a line
using pixel-scroll-up and pixel-scroll-down.

In principle, pixel-scroll-mode wants to scroll a line slowly.
I am on MacBook Pro (Retina, 13-inch, Late 2012) with Mojave 10.14.3,
and so far, I’m happy enough with the performance.



> On Mar 3, 2019, at 5:10 AM, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Sat, Mar 02, 2019 at 07:25:13PM +0900, Tak Kunihiro wrote:
>> On Emacs-26.1.92 build for macOS, I see the mode line flicks when I
>> scroll-up using pixel-scroll-mode and mouse wheel.  The mode line does
>> not flick on scrolling-down.  I do not see this problem in
>> Emacs-26.1.92 build for Windows.
>> 
>> macOS$ /Downloads/emacs-26.1.92/nextstep/Emacs.app/Contents/MacOS/Emacs -Q
>> M-x pixel-scroll-mode
>> M-: (pixel-scroll-up 1) ; => the mode line flicks
>> M-: (pixel-scroll-down 1) ;=> no flick
>> 
>> I narrow down the problem and notice that following
>> two blocks response differently.
>> 
>> #+begin_src emacs-lisp
>> (dolist (vs (number-sequence 1 10))
>>  (set-window-vscroll nil vs t)
>>  (sit-for 0))
>> ;; the mode line flicks
>> #+end_src
>> 
>> #+begin_src emacs-lisp
>> (dolist (vs (number-sequence 1 10))
>>  (set-window-vscroll nil vs t))
>> ;; no flick
>> #+end_src
>> 
>> Do you have idea?
> 
> I believe it’s a problem with running redisplay rapidly (sit-for) and
> the way we’re drawing in NS. We end up with macOS demanding a screen
> update, and Emacs unable to deliver due to there being another
> redisplay coming up.
> 
> The patch attached to this discussion doesn’t have the problem:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2019-02/msg00354.html
> 
> However Robert Pluim reported serious performance problems with it. I
> haven’t been able to replicate them.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Mon, 04 Mar 2019 10:06:20 +0100

Alan Third <alan <at> idiocy.org> writes:

> I believe it’s a problem with running redisplay rapidly (sit-for) and
> the way we’re drawing in NS. We end up with macOS demanding a screen
> update, and Emacs unable to deliver due to there being another
> redisplay coming up.
>
> The patch attached to this discussion doesn’t have the problem:
>
> https://lists.gnu.org/archive/html/emacs-devel/2019-02/msg00354.html
>
> However Robert Pluim reported serious performance problems with it. I
> haven’t been able to replicate them.

I can try it again. Perhaps something in my configuration is causing
this.

Robert

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

From: Alan Third <alan <at> idiocy.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Mon, 4 Mar 2019 19:25:50 +0000

On Mon, Mar 04, 2019 at 10:06:20AM +0100, Robert Pluim wrote:
> Alan Third <alan <at> idiocy.org> writes:
> 
> > I believe it’s a problem with running redisplay rapidly (sit-for) and
> > the way we’re drawing in NS. We end up with macOS demanding a screen
> > update, and Emacs unable to deliver due to there being another
> > redisplay coming up.
> >
> > The patch attached to this discussion doesn’t have the problem:
> >
> > https://lists.gnu.org/archive/html/emacs-devel/2019-02/msg00354.html
> >
> > However Robert Pluim reported serious performance problems with it. I
> > haven’t been able to replicate them.
> 
> I can try it again. Perhaps something in my configuration is causing
> this.

If you can try and track it down that would be very helpful.

The only thing I can think of that could make it very slow is drawing
the buffer to the screen, but that really shouldn’t be as slow as
you’re experiencing, it is, after all, just drawing an image to the
screen.
-- 
Alan Third

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Mon, 04 Mar 2019 22:07:25 +0100

Alan Third <alan <at> idiocy.org> writes:

> On Mon, Mar 04, 2019 at 10:06:20AM +0100, Robert Pluim wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>> 
>> > I believe it’s a problem with running redisplay rapidly (sit-for) and
>> > the way we’re drawing in NS. We end up with macOS demanding a screen
>> > update, and Emacs unable to deliver due to there being another
>> > redisplay coming up.
>> >
>> > The patch attached to this discussion doesn’t have the problem:
>> >
>> > https://lists.gnu.org/archive/html/emacs-devel/2019-02/msg00354.html
>> >
>> > However Robert Pluim reported serious performance problems with it. I
>> > haven’t been able to replicate them.
>> 
>> I can try it again. Perhaps something in my configuration is causing
>> this.
>
> If you can try and track it down that would be very helpful.
>
> The only thing I can think of that could make it very slow is drawing
> the buffer to the screen, but that really shouldn’t be as slow as
> you’re experiencing, it is, after all, just drawing an image to the
> screen.

To be clear: the slowness I experience does not seem wholly related to
redisplay: if I move down in a file using 'C-n', without the buffer
scrolling, the movement is very slow. Then when it does actually
update the screen because Iʼve moved point off the bottom, it is again
slow (by a rough measurement, moving from the top to the bottom of my
org file using C-v is approximately twice as slow).

(this is all with 'emacs -Q')

Iʼve just run another test where I scroll my org file programmatically
rather than interactively, and then your patch makes no discernable
difference:

(benchmark-run 1000
               (goto-char (point-min))
               (condition-case nil
                   (while t
                     (scroll-up-command))
                 (error nil)))
                 
takes ~15 seconds in both vanilla emacs-26 and with your patch.

Are there any other tests you'd like me to run? (I know nothing about
macOS profiling tools)

Robert

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

From: Alan Third <alan <at> idiocy.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Mon, 4 Mar 2019 22:45:53 +0000

On Mon, Mar 04, 2019 at 10:07:25PM +0100, Robert Pluim wrote:
> To be clear: the slowness I experience does not seem wholly related to
> redisplay: if I move down in a file using 'C-n', without the buffer
> scrolling, the movement is very slow. Then when it does actually
> update the screen because Iʼve moved point off the bottom, it is again
> slow (by a rough measurement, moving from the top to the bottom of my
> org file using C-v is approximately twice as slow).
> 
> (this is all with 'emacs -Q')
> 
> Iʼve just run another test where I scroll my org file programmatically
> rather than interactively, and then your patch makes no discernable
> difference:
> 
> (benchmark-run 1000
>                (goto-char (point-min))
>                (condition-case nil
>                    (while t
>                      (scroll-up-command))
>                  (error nil)))
>                  
> takes ~15 seconds in both vanilla emacs-26 and with your patch.
> 
> Are there any other tests you'd like me to run? (I know nothing about
> macOS profiling tools)

Thanks for trying. I can’t think of anything to test right now but
I’ll have a think and get back to you.

What sort of hardware are you running on? Are you running Emacs
fullscreen on a 4k display or similar?
-- 
Alan Third

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Tue, 05 Mar 2019 10:06:02 +0100

Alan Third <alan <at> idiocy.org> writes:

> On Mon, Mar 04, 2019 at 10:07:25PM +0100, Robert Pluim wrote:
>> takes ~15 seconds in both vanilla emacs-26 and with your patch.
>> 
>> Are there any other tests you'd like me to run? (I know nothing about
>> macOS profiling tools)
>
> Thanks for trying. I can’t think of anything to test right now but
> I’ll have a think and get back to you.
>
> What sort of hardware are you running on? Are you running Emacs
> fullscreen on a 4k display or similar?

Itʼs a late 2018 macbook pro 13", i7 cpu. The external monitors are:

(display-monitor-attributes-list)
(((name . "Monitor1")
  (geometry 0 0 1920 1080)
  (workarea 0 23 1920 1057)
  (mm-size 594 334)
  (frames #<frame *Summary gmane.emacs.bugs* 0x7fcda78819b0> #<frame *ielm* 0x7fcdad8efa80>)
  (source . "NS"))
 ((name . "Monitor2")
  (geometry -1920 0 1920 1080)
  (workarea -1920 0 1920 1080)
  (mm-size 594 334)
  (frames)
  (source . "NS")))

so not 4k, and I normally run with multiple non-maximized frames (but
my testing was with a single default frame).

Robert

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Tue, 05 Mar 2019 18:09:41 +0100

Robert Pluim <rpluim <at> gmail.com> writes:

> so not 4k, and I normally run with multiple non-maximized frames (but
> my testing was with a single default frame).

So Iʼve decided that this was all down to key-repeat rate. I had that
set to maximum already, but I went into system preferences, set it
lower, exited emacs, set it back, and now emacs with your patch is OK.

'Did you try rebooting it'ly yours :-)

Robert

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

From: Alan Third <alan <at> idiocy.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Wed, 6 Mar 2019 08:06:22 +0000

On Tue, Mar 05, 2019 at 06:09:41PM +0100, Robert Pluim wrote:
> Robert Pluim <rpluim <at> gmail.com> writes:
> 
> > so not 4k, and I normally run with multiple non-maximized frames (but
> > my testing was with a single default frame).
> 
> So Iʼve decided that this was all down to key-repeat rate. I had that
> set to maximum already, but I went into system preferences, set it
> lower, exited emacs, set it back, and now emacs with your patch is OK.

Good to know, but still sounds like performance could be improved.

And I still can’t replicate it. Perhaps it’s a combination of multiple
factors.

Can you try this patch and see if it improves anything, please?

modified   src/nsterm.m
@@ -1168,7 +1168,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
 #ifdef NS_IMPL_COCOA
   [NSGraphicsContext setCurrentContext:nil];
-  [view display];
 #else
   block_input ();
 
It’s possible this will cause it to drop frames and make things worse.

-- 
Alan Third

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>, 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Wed, 06 Mar 2019 10:13:21 +0100

Alan Third <alan <at> idiocy.org> writes:

> On Tue, Mar 05, 2019 at 06:09:41PM +0100, Robert Pluim wrote:
>> Robert Pluim <rpluim <at> gmail.com> writes:
>> 
>> > so not 4k, and I normally run with multiple non-maximized frames (but
>> > my testing was with a single default frame).
>> 
>> So Iʼve decided that this was all down to key-repeat rate. I had that
>> set to maximum already, but I went into system preferences, set it
>> lower, exited emacs, set it back, and now emacs with your patch is OK.
>
> Good to know, but still sounds like performance could be improved.
>
> And I still can’t replicate it. Perhaps it’s a combination of multiple
> factors.
>
> Can you try this patch and see if it improves anything, please?
>
> modified   src/nsterm.m
> @@ -1168,7 +1168,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
>  
>  #ifdef NS_IMPL_COCOA
>    [NSGraphicsContext setCurrentContext:nil];
> -  [view display];
>  #else
>    block_input ();
>  
> It’s possible this will cause it to drop frames and make things worse.

That makes no perceptible difference in my not-too-accurate test,
which is scrolling my org-file using C-n from top to bottom: ≅ 17
seconds in both cases.

Robert

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

From: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>
To: 34710 <at> debbugs.gnu.org
Subject: Re: bug#34710: the mode line flicks on set-window-vscroll
Date: Thu, 07 Mar 2019 09:25:18 +0900 (JST)

With my casual test, the patch makes pixel-wise scroll 5% faster.


> On Mar 6, 2019, at 17:06 , Alan Third <alan <at> idiocy.org> wrote:
> 
> On Tue, Mar 05, 2019 at 06:09:41PM +0100, Robert Pluim wrote:
>> Robert Pluim <rpluim <at> gmail.com> writes:
>> 
>>> so not 4k, and I normally run with multiple non-maximized frames (but
>>> my testing was with a single default frame).
>> 
>> So Iʼve decided that this was all down to key-repeat rate. I had that
>> set to maximum already, but I went into system preferences, set it
>> lower, exited emacs, set it back, and now emacs with your patch is OK.
> 
> Good to know, but still sounds like performance could be improved.
> 
> And I still can’t replicate it. Perhaps it’s a combination of multiple
> factors.
> 
> Can you try this patch and see if it improves anything, please?
> 
> modified   src/nsterm.m
> @@ -1168,7 +1168,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
> 
> #ifdef NS_IMPL_COCOA
>   [NSGraphicsContext setCurrentContext:nil];
> -  [view display];
> #else
>   block_input ();
> 
> It’s possible this will cause it to drop frames and make things worse.

Previous Next

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