bug#34710: the mode line flicks on set-window-vscroll

bug#34710: the mode line flicks on set-window-vscroll

[Tak Kunihiro]

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?

bug#34710: the mode line flicks on set-window-vscroll

[Alan Third]

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

bug#34710: the mode line flicks on set-window-vscroll

[Tak Kunihiro]

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

bug#34710: the mode line flicks on set-window-vscroll

[Robert Pluim]

Alan Third <alan@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

bug#34710: the mode line flicks on set-window-vscroll

[Alan Third]

On Mon, Mar 04, 2019 at 10:06:20AM +0100, Robert Pluim wrote:
> Alan Third <alan@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

bug#34710: the mode line flicks on set-window-vscroll

[Robert Pluim]

Alan Third <alan@idiocy.org> writes:

> On Mon, Mar 04, 2019 at 10:06:20AM +0100, Robert Pluim wrote:
>> Alan Third <alan@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

bug#34710: the mode line flicks on set-window-vscroll

[Alan Third]

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

bug#34710: the mode line flicks on set-window-vscroll

[Robert Pluim]

Alan Third <alan@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

bug#34710: the mode line flicks on set-window-vscroll

[Robert Pluim]

Robert Pluim <rpluim@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

bug#34710: the mode line flicks on set-window-vscroll

[Alan Third]

On Tue, Mar 05, 2019 at 06:09:41PM +0100, Robert Pluim wrote:
> Robert Pluim <rpluim@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

bug#34710: the mode line flicks on set-window-vscroll

[Robert Pluim]

Alan Third <alan@idiocy.org> writes:

> On Tue, Mar 05, 2019 at 06:09:41PM +0100, Robert Pluim wrote:
>> Robert Pluim <rpluim@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

bug#34710: the mode line flicks on set-window-vscroll

[Tak Kunihiro]

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


> On Mar 6, 2019, at 17:06 , Alan Third <alan@idiocy.org> wrote:
> 
> On Tue, Mar 05, 2019 at 06:09:41PM +0100, Robert Pluim wrote:
>> Robert Pluim <rpluim@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.