bug#42406: Mouse-wheel scrolling can be flickering

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

Mouse-wheel scroll and then suddenly release the mouse-wheel, so that thereafter the text scrolled still moves for a short time. During that time, the text flickers.

(In case this is platform-dependent, I use the NS-port of Emacs 27.0.91/pretest)

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Fri, Jul 17, 2020 at 05:36:10PM +0200, Konrad Podczeck wrote:
> Mouse-wheel scroll and then suddenly release the mouse-wheel, so
> that thereafter the text scrolled still moves for a short time.
> During that time, the text flickers.
> 
> (In case this is platform-dependent, I use the NS-port of Emacs
> 27.0.91/pretest)

Emacs 28 will use a different method of drawing to the screen that
should, hopefully, not flicker. Can you please try out a build from
master and see if it's any better?
-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

For me, there is no difference with Emacs 28. To see this best, make the following customizations:

(setq mouse-wheel-progressive-speed nil)
(setq mouse-wheel-scroll-amount '(1 ((shift) . 1)))

(and make sure that in the Mouse Options part of the Accessibilty panel of the general System Preferences of MacOS, scrolling with inertia is enabled.)


> Am 19.07.2020 um 15:33 schrieb Alan Third <alan@idiocy.org>:
> 
> On Fri, Jul 17, 2020 at 05:36:10PM +0200, Konrad Podczeck wrote:
>> Mouse-wheel scroll and then suddenly release the mouse-wheel, so
>> that thereafter the text scrolled still moves for a short time.
>> During that time, the text flickers.
>> 
>> (In case this is platform-dependent, I use the NS-port of Emacs
>> 27.0.91/pretest)
> 
> Emacs 28 will use a different method of drawing to the screen that
> should, hopefully, not flicker. Can you please try out a build from
> master and see if it's any better?
> -- 
> Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Sun, Jul 19, 2020 at 10:29:20PM +0200, Konrad Podczeck wrote:
> For me, there is no difference with Emacs 28. To see this best, make the following customizations:
> 
> (setq mouse-wheel-progressive-speed nil)
> (setq mouse-wheel-scroll-amount '(1 ((shift) . 1)))
> 
> (and make sure that in the Mouse Options part of the Accessibilty
> panel of the general System Preferences of MacOS, scrolling with
> inertia is enabled.)

What version of macOS are you using? I can't get momentum working here
any more and I don't have any option that I can see in the system
preferences to turn it on or off.

I can't think of any reason that momentum scrolling should flicker
when normal scrolling doesn't, they use the exact same mechanism.

Does it happen when you run emacs -Q?
-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

Having taken a closer look, it seems to me now that what I called "flickering" is the following:

Mouse-wheel scroll downwards, so that the cursor becomes positioned at the top row of the frame. Then release the mouse-wheel, but so that inertia scrolling continues for a short time. After the scrolling comes to rest, which is probably determined by the window manager, there is an extra movement, governed probably by Emacs, to make sure that it is not the case that only, say, half of a row is visible at the top of the frame. It seems to me that it is this extra movement which leads to what I called "flickering."


For how to enable/disable "inertia scrolling, see

https://support.apple.com/en-nz/guide/mac-help/unac899/mac


> Am 22.07.2020 um 22:16 schrieb Alan Third <alan@idiocy.org>:
> 
> On Sun, Jul 19, 2020 at 10:29:20PM +0200, Konrad Podczeck wrote:
>> For me, there is no difference with Emacs 28. To see this best, make the following customizations:
>> 
>> (setq mouse-wheel-progressive-speed nil)
>> (setq mouse-wheel-scroll-amount '(1 ((shift) . 1)))
>> 
>> (and make sure that in the Mouse Options part of the Accessibilty
>> panel of the general System Preferences of MacOS, scrolling with
>> inertia is enabled.)
> 
> What version of macOS are you using? I can't get momentum working here
> any more and I don't have any option that I can see in the system
> preferences to turn it on or off.
> 
> I can't think of any reason that momentum scrolling should flicker
> when normal scrolling doesn't, they use the exact same mechanism.
> 
> Does it happen when you run emacs -Q?
> -- 
> Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Thu, Jul 30, 2020 at 12:30:27PM +0200, Konrad Podczeck wrote:
> Having taken a closer look, it seems to me now that what I called "flickering" is the following:
> 
> Mouse-wheel scroll downwards, so that the cursor becomes positioned
> at the top row of the frame. Then release the mouse-wheel, but so
> that inertia scrolling continues for a short time. After the
> scrolling comes to rest, which is probably determined by the window
> manager, there is an extra movement, governed probably by Emacs, to
> make sure that it is not the case that only, say, half of a row is
> visible at the top of the frame. It seems to me that it is this
> extra movement which leads to what I called "flickering."

I'm afraid I don't follow. The NS port doesn't let you scroll by part
of a line by default. Are you using pixel-scroll-mode or similar?

If I use pixel-scroll-mode I can see some flickering of the mode line
after scrolling has ceased (as you say, when it rolls back or forth to
show a whole line), but only in Emacs 27, Emacs 28 is fine.

> For how to enable/disable "inertia scrolling, see
> 
> https://support.apple.com/en-nz/guide/mac-help/unac899/mac

Thanks, strangely I don't see what they describe there... My Mac must
have something odd going on... :/
-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Thu, Jul 30, 2020 at 12:30:27PM +0200, Konrad Podczeck wrote:
> Having taken a closer look, it seems to me now that what I called "flickering" is the following:
> 
> Mouse-wheel scroll downwards, so that the cursor becomes positioned
> at the top row of the frame. Then release the mouse-wheel, but so
> that inertia scrolling continues for a short time. After the
> scrolling comes to rest, which is probably determined by the window
> manager, there is an extra movement, governed probably by Emacs, to
> make sure that it is not the case that only, say, half of a row is
> visible at the top of the frame. It seems to me that it is this
> extra movement which leads to what I called "flickering."

Sorry for the long delay. In standard Emacs usage you shouldn't ever
see half a line displayed at the top of the screen. Are you using
pixel scroll mode or something?

The only alternative I can think of is that the inertia just pushes it
over the edge to scroll one more line, but I don't think you would see
that as "flickering", just an extra scroll.

To disable inertia in Emacs do:

    (setq ns-use-mwheel-momentum nil)

-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

> Am 10.10.2020 um 11:51 schrieb Alan Third <alan@idiocy.org>:
> 
> On Thu, Jul 30, 2020 at 12:30:27PM +0200, Konrad Podczeck wrote:
>> Having taken a closer look, it seems to me now that what I called "flickering" is the following:
>> 
>> Mouse-wheel scroll downwards, so that the cursor becomes positioned
>> at the top row of the frame. Then release the mouse-wheel, but so
>> that inertia scrolling continues for a short time. After the
>> scrolling comes to rest, which is probably determined by the window
>> manager, there is an extra movement, governed probably by Emacs, to
>> make sure that it is not the case that only, say, half of a row is
>> visible at the top of the frame. It seems to me that it is this
>> extra movement which leads to what I called "flickering."
> 
> Sorry for the long delay. In standard Emacs usage you shouldn't ever
> see half a line displayed at the top of the screen. Are you using
> pixel scroll mode or something?

No

> 
> The only alternative I can think of is that the inertia just pushes it
> over the edge to scroll one more line, but I don't think you would see
> that as "flickering", just an extra scroll.

Yes, maybe “flickering” is saying to much, but I see a “light tremor”, at least with the customizations:

(setq mouse-wheel-progressive-speed nil)
(setq mouse-wheel-scroll-amount '(1 ((shift) . 1)))

Konrad

> 
> To disable inertia in Emacs do:
> 
>    (setq ns-use-mwheel-momentum nil)
> 
> -- 
> Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

I still see a problem with mouse wheel scrolling, for emacs from the 27 branch as well as for emacs from the master branch, when there are multiple frames open.

To reproduce: Start Emacs (from any of the two mentioned branches) with an init-file just containing:

(setq mouse-wheel-progressive-speed nil)

(setq default-frame-alist '((tool-bar-lines . 1)(width . 82)(height . 46)(left . 1)(top . 0)(font . "SF Mono-15")(line-spacing . 3)))

Open any longer file. Mouse wheel scrolling performance is fine (at least for the master branch). Now do C-x 5 2, to get a second frame. Using the mouse wheel, scroll up and down. Repeat C-x 5 2, about six times, and the scrolling performance becomes worse and worse.

Remark: If one uses the menu to turn off the toolbar, then the problem disappears.

Remark: Instead of customizing default-frame-alist, one can also put the following code in the init-file

(custom-set-variables
 '(display-buffer-base-action
   '((display-buffer-reuse-window display-buffer-pop-up-frame)
    (reusable-frames . t)))
 '(display-buffer-alist
   '(
    ("[.]"
     (display-buffer-reuse-window display-buffer-pop-up-frame)
     (pop-up-frame-parameters
       (tool-bar-lines . 1)
       (left . 1)
       (top . 0)
       (height . 46)
       (width . 82)
       (font . "SF Mono-15")
       (line-spacing . 3)
      ))))
)

to get the the same problem with different buffers.

Konrad



> Am 10.10.2020 um 16:07 schrieb Konrad Podczeck <konrad.podczeck@univie.ac.at>:
> 
> 
> 
>> Am 10.10.2020 um 11:51 schrieb Alan Third <alan@idiocy.org>:
>> 
>> On Thu, Jul 30, 2020 at 12:30:27PM +0200, Konrad Podczeck wrote:
>>> Having taken a closer look, it seems to me now that what I called "flickering" is the following:
>>> 
>>> Mouse-wheel scroll downwards, so that the cursor becomes positioned
>>> at the top row of the frame. Then release the mouse-wheel, but so
>>> that inertia scrolling continues for a short time. After the
>>> scrolling comes to rest, which is probably determined by the window
>>> manager, there is an extra movement, governed probably by Emacs, to
>>> make sure that it is not the case that only, say, half of a row is
>>> visible at the top of the frame. It seems to me that it is this
>>> extra movement which leads to what I called "flickering."
>> 
>> Sorry for the long delay. In standard Emacs usage you shouldn't ever
>> see half a line displayed at the top of the screen. Are you using
>> pixel scroll mode or something?
> 
> No
> 
>> 
>> The only alternative I can think of is that the inertia just pushes it
>> over the edge to scroll one more line, but I don't think you would see
>> that as "flickering", just an extra scroll.
> 
> Yes, maybe “flickering” is saying to much, but I see a “light tremor”, at least with the customizations:
> 
> (setq mouse-wheel-progressive-speed nil)
> (setq mouse-wheel-scroll-amount '(1 ((shift) . 1)))
> 
> Konrad
> 
>> 
>> To disable inertia in Emacs do:
>> 
>>   (setq ns-use-mwheel-momentum nil)
>> 
>> -- 
>> Alan Third


[-- Attachment #2: Type: text/html, Size: 12413 bytes --]

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Thu, Dec 10, 2020 at 06:14:30PM +0100, Konrad Podczeck wrote:
> I still see a problem with mouse wheel scrolling, for emacs from the
> 27 branch as well as for emacs from the master branch, when there
> are multiple frames open.
> 
> To reproduce: Start Emacs (from any of the two mentioned branches)
> with an init-file just containing:
> 
> (setq mouse-wheel-progressive-speed nil)
> 
> (setq default-frame-alist '((tool-bar-lines . 1)(width . 82)(height . 46)(left . 1)(top . 0)(font . "SF Mono-15")(line-spacing . 3)))
> 
> Open any longer file. Mouse wheel scrolling performance is fine (at
> least for the master branch). Now do C-x 5 2, to get a second frame.
> Using the mouse wheel, scroll up and down. Repeat C-x 5 2, about six
> times, and the scrolling performance becomes worse and worse.
> 
> Remark: If one uses the menu to turn off the toolbar, then the problem disappears.

OK, I can see this. Turning off the menu doesn't actually make it go
away, it just makes the redraw more efficient, so you need more frames
open to see the effect.

What appears to be happening is that scrolling with the mouse, and
also using C-v or M-v causes every frame to update the cursor and
clear the internal border, which in turn causes them all to be drawn
to the screen at once, which is pretty slow.

(It also appears to do something with scrollbars which helped me find a
subtle redrawing bug.)

Scrolling through the buffer by using C-n to move down line by line
only updates the frame being displayed. I'm not sure what's going on,
it appears to be system independent code doing this.
-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Date: Thu, 10 Dec 2020 22:10:28 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 42406@debbugs.gnu.org
> 
> What appears to be happening is that scrolling with the mouse, and
> also using C-v or M-v causes every frame to update the cursor and
> clear the internal border, which in turn causes them all to be drawn
> to the screen at once, which is pretty slow.
> 
> (It also appears to do something with scrollbars which helped me find a
> subtle redrawing bug.)
> 
> Scrolling through the buffer by using C-n to move down line by line
> only updates the frame being displayed. I'm not sure what's going on,
> it appears to be system independent code doing this.

Any pointers to the code which causes all the frames to be updated in
C-v/M-v case?

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Fri, Dec 11, 2020 at 10:18:14AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 10 Dec 2020 22:10:28 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: 42406@debbugs.gnu.org
> > 
> > What appears to be happening is that scrolling with the mouse, and
> > also using C-v or M-v causes every frame to update the cursor and
> > clear the internal border, which in turn causes them all to be drawn
> > to the screen at once, which is pretty slow.
> > 
> > (It also appears to do something with scrollbars which helped me find a
> > subtle redrawing bug.)
> > 
> > Scrolling through the buffer by using C-n to move down line by line
> > only updates the frame being displayed. I'm not sure what's going on,
> > it appears to be system independent code doing this.
> 
> Any pointers to the code which causes all the frames to be updated in
> C-v/M-v case?

I don't know. I'm looking at redisplay_internal in a debugger and I
can see that consider_all_windows_p is true, which will be because
windows_or_buffers_changed == 2 == REDISPLAY_SOME or because
update_mode_lines == 42.

I can't find anywhere that sets update_mode_lines to 42...

In my case both frames are displaying different buffers. The one I'm
scrolling is displaying xdisp.c and the other is displaying *scratch*.

-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Date: Fri, 11 Dec 2020 20:37:56 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org
> 
> > Any pointers to the code which causes all the frames to be updated in
> > C-v/M-v case?
> 
> I don't know. I'm looking at redisplay_internal in a debugger and I
> can see that consider_all_windows_p is true, which will be because
> windows_or_buffers_changed == 2 == REDISPLAY_SOME or because
> update_mode_lines == 42.
> 
> I can't find anywhere that sets update_mode_lines to 42...

wset_update_mode_line does it, so any caller of that function would.

But where do you see the value of 42 being tested?

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Sun, Dec 13, 2020 at 09:05:29PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 11 Dec 2020 20:37:56 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org
> > 
> > > Any pointers to the code which causes all the frames to be updated in
> > > C-v/M-v case?
> > 
> > I don't know. I'm looking at redisplay_internal in a debugger and I
> > can see that consider_all_windows_p is true, which will be because
> > windows_or_buffers_changed == 2 == REDISPLAY_SOME or because
> > update_mode_lines == 42.
> > 
> > I can't find anywhere that sets update_mode_lines to 42...
> 
> wset_update_mode_line does it, so any caller of that function would.
> 
> But where do you see the value of 42 being tested?

I've got two frames open, I set up a breakpoint in
ns_clear_under_internal_border and scroll. When I hit the breakpoint
for the frame I don't expect to be updated I get this backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001001eb35f temacs`ns_clear_under_internal_border(f=0x000000010711cea0) at nsterm.m:3036:7 [opt]
    frame #1: 0x0000000100029cd5 temacs`redisplay_internal at xdisp.c:16030:21 [opt]
    frame #2: 0x00000001000cb1d5 temacs`read_char(commandflag=1, map=0x0000000107d635c3, prev_event=0x0000000000000000, used_mouse_menu=0x00007ffeefbff36b, end_time=0x0000000000000000) at keyboard.c:2496:6 [opt]
    frame #3: 0x00000001000c8e72 temacs`read_key_sequence(keybuf=<unavailable>, prompt=0x0000000000000000, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) at keyboard.c:9483:12 [opt]
    frame #4: 0x00000001000c756c temacs`command_loop_1 at keyboard.c:1353:15 [opt]
    frame #5: 0x000000010014dd17 temacs`internal_condition_case(bfun=(temacs`command_loop_1 at keyboard.c:1239), handlers=0x0000000000000090, hfun=(temacs`cmd_error at keyboard.c:922)) at eval.c:1415:25 [opt]
    frame #6: 0x00000001000d7670 temacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1094:11 [opt]
    frame #7: 0x000000010014d53b temacs`internal_catch(tag=0x000000000000c9f0, func=(temacs`command_loop_2 at keyboard.c:1090), arg=0x0000000000000000) at eval.c:1176:25 [opt]
    frame #8: 0x0000000100212935 temacs`command_loop.cold.1 + 69
    frame #9: 0x00000001000c6633 temacs`command_loop at keyboard.c:1072:2 [opt]
    frame #10: 0x00000001000c6563 temacs`recursive_edit_1 at keyboard.c:720:9 [opt]
    frame #11: 0x00000001000c67bb temacs`Frecursive_edit at keyboard.c:789:3 [opt]
    frame #12: 0x00000001000c5343 temacs`main(argc=<unavailable>, argv=0x00007ffeefbff810) at emacs.c:2054:3 [opt]
    frame #13: 0x00007fff712cd3d5 libdyld.dylib`start + 1* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001001eb35f temacs`ns_clear_under_internal_border(f=0x000000010711cea0) at nsterm.m:3036:7 [opt]
    frame #1: 0x0000000100029cd5 temacs`redisplay_internal at xdisp.c:16030:21 [opt]
    frame #2: 0x00000001000cb1d5 temacs`read_char(commandflag=1, map=0x0000000107d635c3, prev_event=0x0000000000000000, used_mouse_menu=0x00007ffeefbff36b, end_time=0x0000000000000000) at keyboard.c:2496:6 [opt]
    frame #3: 0x00000001000c8e72 temacs`read_key_sequence(keybuf=<unavailable>, prompt=0x0000000000000000, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) at keyboard.c:9483:12 [opt]
    frame #4: 0x00000001000c756c temacs`command_loop_1 at keyboard.c:1353:15 [opt]
    frame #5: 0x000000010014dd17 temacs`internal_condition_case(bfun=(temacs`command_loop_1 at keyboard.c:1239), handlers=0x0000000000000090, hfun=(temacs`cmd_error at keyboard.c:922)) at eval.c:1415:25 [opt]
    frame #6: 0x00000001000d7670 temacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1094:11 [opt]
    frame #7: 0x000000010014d53b temacs`internal_catch(tag=0x000000000000c9f0, func=(temacs`command_loop_2 at keyboard.c:1090), arg=0x0000000000000000) at eval.c:1176:25 [opt]
    frame #8: 0x0000000100212935 temacs`command_loop.cold.1 + 69
    frame #9: 0x00000001000c6633 temacs`command_loop at keyboard.c:1072:2 [opt]
    frame #10: 0x00000001000c6563 temacs`recursive_edit_1 at keyboard.c:720:9 [opt]
    frame #11: 0x00000001000c67bb temacs`Frecursive_edit at keyboard.c:789:3 [opt]
    frame #12: 0x00000001000c5343 temacs`main(argc=<unavailable>, argv=0x00007ffeefbff810) at emacs.c:2054:3 [opt]
    frame #13: 0x00007fff712cd3d5 libdyld.dylib`start + 1

Which I've not found very useful. I had a look at redisplay_internal
to see if I could work out why the frame is being updated, but I
can't.

I looked at some of the variables in redisplay_internal that are
involved in making the decision whether to check all frames:

(lldb) p update_mode_lines;
(int) $0 = 42
(lldb) p windows_or_buffers_changed
(int) $1 = 2

but I have no idea if this is useful at all.

Is there anything specific you'd like me to check?
-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

In view of the comments made by Eli, I made a shoot in the dark, and, in window.c, commented out the occurrences of wset_update_mode_line on lines 1850, 4011, 5630, 5819, 6079, as well as the respective line after the three statements lines where "Bug#15957" is written. With these (actually I have not testes which of these (out-commentings are relevant) the problem has completely gone. I am aware that this is not a real solution, but it shows that there is some room. Which are the risks caused by these changes of the code?

> Am 13.12.2020 um 20:46 schrieb Alan Third <alan@idiocy.org>:
> 
> On Sun, Dec 13, 2020 at 09:05:29PM +0200, Eli Zaretskii wrote:
>>> Date: Fri, 11 Dec 2020 20:37:56 +0000
>>> From: Alan Third <alan@idiocy.org>
>>> Cc: konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org
>>> 
>>>> Any pointers to the code which causes all the frames to be updated in
>>>> C-v/M-v case?
>>> 
>>> I don't know. I'm looking at redisplay_internal in a debugger and I
>>> can see that consider_all_windows_p is true, which will be because
>>> windows_or_buffers_changed == 2 == REDISPLAY_SOME or because
>>> update_mode_lines == 42.
>>> 
>>> I can't find anywhere that sets update_mode_lines to 42...
>> 
>> wset_update_mode_line does it, so any caller of that function would.
>> 
>> But where do you see the value of 42 being tested?
> 
> I've got two frames open, I set up a breakpoint in
> ns_clear_under_internal_border and scroll. When I hit the breakpoint
> for the frame I don't expect to be updated I get this backtrace:
> 
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>  * frame #0: 0x00000001001eb35f temacs`ns_clear_under_internal_border(f=0x000000010711cea0) at nsterm.m:3036:7 [opt]
>    frame #1: 0x0000000100029cd5 temacs`redisplay_internal at xdisp.c:16030:21 [opt]
>    frame #2: 0x00000001000cb1d5 temacs`read_char(commandflag=1, map=0x0000000107d635c3, prev_event=0x0000000000000000, used_mouse_menu=0x00007ffeefbff36b, end_time=0x0000000000000000) at keyboard.c:2496:6 [opt]
>    frame #3: 0x00000001000c8e72 temacs`read_key_sequence(keybuf=<unavailable>, prompt=0x0000000000000000, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) at keyboard.c:9483:12 [opt]
>    frame #4: 0x00000001000c756c temacs`command_loop_1 at keyboard.c:1353:15 [opt]
>    frame #5: 0x000000010014dd17 temacs`internal_condition_case(bfun=(temacs`command_loop_1 at keyboard.c:1239), handlers=0x0000000000000090, hfun=(temacs`cmd_error at keyboard.c:922)) at eval.c:1415:25 [opt]
>    frame #6: 0x00000001000d7670 temacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1094:11 [opt]
>    frame #7: 0x000000010014d53b temacs`internal_catch(tag=0x000000000000c9f0, func=(temacs`command_loop_2 at keyboard.c:1090), arg=0x0000000000000000) at eval.c:1176:25 [opt]
>    frame #8: 0x0000000100212935 temacs`command_loop.cold.1 + 69
>    frame #9: 0x00000001000c6633 temacs`command_loop at keyboard.c:1072:2 [opt]
>    frame #10: 0x00000001000c6563 temacs`recursive_edit_1 at keyboard.c:720:9 [opt]
>    frame #11: 0x00000001000c67bb temacs`Frecursive_edit at keyboard.c:789:3 [opt]
>    frame #12: 0x00000001000c5343 temacs`main(argc=<unavailable>, argv=0x00007ffeefbff810) at emacs.c:2054:3 [opt]
>    frame #13: 0x00007fff712cd3d5 libdyld.dylib`start + 1* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>  * frame #0: 0x00000001001eb35f temacs`ns_clear_under_internal_border(f=0x000000010711cea0) at nsterm.m:3036:7 [opt]
>    frame #1: 0x0000000100029cd5 temacs`redisplay_internal at xdisp.c:16030:21 [opt]
>    frame #2: 0x00000001000cb1d5 temacs`read_char(commandflag=1, map=0x0000000107d635c3, prev_event=0x0000000000000000, used_mouse_menu=0x00007ffeefbff36b, end_time=0x0000000000000000) at keyboard.c:2496:6 [opt]
>    frame #3: 0x00000001000c8e72 temacs`read_key_sequence(keybuf=<unavailable>, prompt=0x0000000000000000, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) at keyboard.c:9483:12 [opt]
>    frame #4: 0x00000001000c756c temacs`command_loop_1 at keyboard.c:1353:15 [opt]
>    frame #5: 0x000000010014dd17 temacs`internal_condition_case(bfun=(temacs`command_loop_1 at keyboard.c:1239), handlers=0x0000000000000090, hfun=(temacs`cmd_error at keyboard.c:922)) at eval.c:1415:25 [opt]
>    frame #6: 0x00000001000d7670 temacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1094:11 [opt]
>    frame #7: 0x000000010014d53b temacs`internal_catch(tag=0x000000000000c9f0, func=(temacs`command_loop_2 at keyboard.c:1090), arg=0x0000000000000000) at eval.c:1176:25 [opt]
>    frame #8: 0x0000000100212935 temacs`command_loop.cold.1 + 69
>    frame #9: 0x00000001000c6633 temacs`command_loop at keyboard.c:1072:2 [opt]
>    frame #10: 0x00000001000c6563 temacs`recursive_edit_1 at keyboard.c:720:9 [opt]
>    frame #11: 0x00000001000c67bb temacs`Frecursive_edit at keyboard.c:789:3 [opt]
>    frame #12: 0x00000001000c5343 temacs`main(argc=<unavailable>, argv=0x00007ffeefbff810) at emacs.c:2054:3 [opt]
>    frame #13: 0x00007fff712cd3d5 libdyld.dylib`start + 1
> 
> Which I've not found very useful. I had a look at redisplay_internal
> to see if I could work out why the frame is being updated, but I
> can't.
> 
> I looked at some of the variables in redisplay_internal that are
> involved in making the decision whether to check all frames:
> 
> (lldb) p update_mode_lines;
> (int) $0 = 42
> (lldb) p windows_or_buffers_changed
> (int) $1 = 2
> 
> but I have no idea if this is useful at all.
> 
> Is there anything specific you'd like me to check?
> -- 
> Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > In view of the comments made by Eli, I made a shoot in the dark, and,
 >  in window.c, commented out the occurrences of wset_update_mode_line
 >  on lines 1850, 4011, 5630, 5819, 6079, as well as the respective line
 >  after the three statements lines where "Bug#15957" is written. With
 >  these (actually I have not testes which of these (out-commentings are
 >  relevant) the problem has completely gone. I am aware that this is
 >  not a real solution, but it shows that there is some room. Which are
 >  the risks caused by these changes of the code?

Does the line number displayed in the mode line update correctly when
you do that and scroll the window?

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Date: Sun, 13 Dec 2020 19:46:04 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org
> 
> Which I've not found very useful. I had a look at redisplay_internal
> to see if I could work out why the frame is being updated, but I
> can't.

AFAIU, it is updated because update_mode_lines is non-zero.

> I looked at some of the variables in redisplay_internal that are
> involved in making the decision whether to check all frames:
> 
> (lldb) p update_mode_lines;
> (int) $0 = 42
> (lldb) p windows_or_buffers_changed
> (int) $1 = 2
> 
> but I have no idea if this is useful at all.
> 
> Is there anything specific you'd like me to check?

I think the issue is clear: mouse-scroll calls scrolling commands, and
all of the scrolling commands set update_mode_lines.  Why they do that
is explained by the comment in wset_update_mode_line:

  /* If this window is the selected window on its frame, set the
     global variable update_mode_lines, so that gui_consider_frame_title
     will consider this frame's title for redisplay.  */

We need to update the mode lines due to scrolling, because mode lines
show the buffer position and other related info.  And please keep in
mind that the frame title can use almost any %-construct defined for
the mode line, so we may need to recompute it as well, when we scroll.
And there's no mechanism in redisplay to redraw portions of the frame
(i.e. something that doesn't belong to any window) except by setting
consider_all_windows_p non-zero.  The effect of that is to consider
all the windows on all the frames for redisplay.  But while Emacs can
refrain from actually redrawing on the glass the parts that it
controls (text displayed in the window etc.), it cannot refrain from
redrawing the parts that are under the control of the GUI toolkit or
the VW.  Which is why you see some portions of the frame flicker.

IOW, the flickering in this case is expected, and cannot be avoided
without making the display engine more fine-grained wrt which parts
need redrawing and when.  The usual method of avoiding flickering is
by double-buffering, but that isn't supported on NS, is it?

However, this bug report said that scrolling becomes slower and slower
with time, and that is not expected, and I see no direct relation
between that and flickering.  Can we please go back to that aspect of
the problem?  It shouldn't happen.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> Date: Mon, 14 Dec 2020 01:20:39 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  42406@debbugs.gnu.org
> 
> In view of the comments made by Eli, I made a shoot in the dark, and, in window.c, commented out the occurrences of wset_update_mode_line on lines 1850, 4011, 5630, 5819, 6079, as well as the respective line after the three statements lines where "Bug#15957" is written. With these (actually I have not testes which of these (out-commentings are relevant) the problem has completely gone. I am aware that this is not a real solution, but it shows that there is some room. Which are the risks caused by these changes of the code?

As explained in my other message, avoiding to call
wset_update_mode_line will cause subtle redisplay bugs.

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Mon, Dec 14, 2020 at 06:12:01PM +0200, Eli Zaretskii wrote:
> We need to update the mode lines due to scrolling, because mode lines
> show the buffer position and other related info.  And please keep in
> mind that the frame title can use almost any %-construct defined for
> the mode line, so we may need to recompute it as well, when we scroll.
> And there's no mechanism in redisplay to redraw portions of the frame
> (i.e. something that doesn't belong to any window) except by setting
> consider_all_windows_p non-zero.  The effect of that is to consider
> all the windows on all the frames for redisplay.  But while Emacs can
> refrain from actually redrawing on the glass the parts that it
> controls (text displayed in the window etc.), it cannot refrain from
> redrawing the parts that are under the control of the GUI toolkit or
> the VW.  Which is why you see some portions of the frame flicker.
> 
> IOW, the flickering in this case is expected, and cannot be avoided
> without making the display engine more fine-grained wrt which parts
> need redrawing and when.  The usual method of avoiding flickering is
> by double-buffering, but that isn't supported on NS, is it?
> 
> However, this bug report said that scrolling becomes slower and slower
> with time, and that is not expected, and I see no direct relation
> between that and flickering.  Can we please go back to that aspect of
> the problem?  It shouldn't happen.

I don't see any flickering. I only see the performance reduction when
multiple frames are open.

That happens because drawing to the glass is slow, and the more we
draw to the screen, the longer it takes. When scrolling frame A, frame
B (and C, and D, etc., etc.) has its internal border and cursor(s)
redrawn.

If we MUST redraw these when nothing on the frame is to be updated,
then I don't see there's very much we can do. I've spent a lot of time
trying to improve performance of drawing to the screen and I don't
have the knowledge required to improve it any further.

I think our only next step is to move to hardware acceleration, but
that's not available on a Free system, afaict, so is banned, and I
don't know how to go about doing that anyway.

For the record: redrawing the internal border will cause all versions
of the NS port to redraw the entire frame, because Cocoa only allows
you to select rectangles to redraw, and it joins any contiguous
rectangles together into bigger rectangles, and the internal border
forms a rectangle containing the entire frame contents.

Perhaps I should get rid of the internal border code, it's new to the
NS port in Emacs 28.

-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

> Am 14.12.2020 um 16:47 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > In view of the comments made by Eli, I made a shoot in the dark, and,
> >  in window.c, commented out the occurrences of wset_update_mode_line
> >  on lines 1850, 4011, 5630, 5819, 6079, as well as the respective line
> >  after the three statements lines where "Bug#15957" is written. With
> >  these (actually I have not testes which of these (out-commentings are
> >  relevant) the problem has completely gone. I am aware that this is
> >  not a real solution, but it shows that there is some room. Which are
> >  the risks caused by these changes of the code?
> 
> Does the line number displayed in the mode line update correctly when
> you do that and scroll the window?

Yes, as before. Should there be a problem now?
> 
> martin

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

> Am 14.12.2020 um 17:17 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
>> Date: Mon, 14 Dec 2020 01:20:39 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> 42406@debbugs.gnu.org
>> 
>> In view of the comments made by Eli, I made a shoot in the dark, and, in window.c, commented out the occurrences of wset_update_mode_line on lines 1850, 4011, 5630, 5819, 6079, as well as the respective line after the three statements lines where "Bug#15957" is written. With these (actually I have not testes which of these (out-commentings are relevant) the problem has completely gone. I am aware that this is not a real solution, but it shows that there is some room. Which are the risks caused by these changes of the code?
> 
> As explained in my other message, avoiding to call
> wset_update_mode_line will cause subtle redisplay bugs.
 
Which bug could I encounter, for example?

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Date: Mon, 14 Dec 2020 20:25:30 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org
> 
> > However, this bug report said that scrolling becomes slower and slower
> > with time, and that is not expected, and I see no direct relation
> > between that and flickering.  Can we please go back to that aspect of
> > the problem?  It shouldn't happen.
> 
> I don't see any flickering. I only see the performance reduction when
> multiple frames are open.

If the performance hit is only a function of how many frames are
there, then this is expected.  I thought the performance got worse
with time, but maybe I misunderstood.

> If we MUST redraw these when nothing on the frame is to be updated,
> then I don't see there's very much we can do.

The problem is, we don't know whether something's changed.

OTOH, continuous scrolling is not supposed to be a frequent use
pattern in Emacs.

> Perhaps I should get rid of the internal border code, it's new to the
> NS port in Emacs 28.

You could definitely make it optional, so that people who'd like
faster redisplay could decide whether they are okay with giving up the
internal border.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> Date: Mon, 14 Dec 2020 21:48:36 +0100
> Cc: Alan Third <alan@idiocy.org>,
>  42406@debbugs.gnu.org
> 
> > As explained in my other message, avoiding to call
> > wset_update_mode_line will cause subtle redisplay bugs.
>  
> Which bug could I encounter, for example?

Mode lines of non-selected windows could fail to update when they
should (e.g., if the buffer displayed in a non-selected window
changes), tool-bar buttons that change their appearance depending on
the Emacs state (e.g., the "Copy" button becomes sensitive only when
there's region) could fail to react to state changes, menu-bar items
that depend on modes and global state could fail to update.  That sort
of bugs.

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Mon, Dec 14, 2020 at 10:54:33PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 14 Dec 2020 20:25:30 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: konrad.podczeck@univie.ac.at, 42406@debbugs.gnu.org
> > 
> > > However, this bug report said that scrolling becomes slower and slower
> > > with time, and that is not expected, and I see no direct relation
> > > between that and flickering.  Can we please go back to that aspect of
> > > the problem?  It shouldn't happen.
> > 
> > I don't see any flickering. I only see the performance reduction when
> > multiple frames are open.
> 
> If the performance hit is only a function of how many frames are
> there, then this is expected.  I thought the performance got worse
> with time, but maybe I misunderstood.

I only see it as a function of how many frames are open. It doesn't
seem to get worse with time.

I guess we just add this but report to the list of complaints that the
NS port is terrible at drawing to the screen.
-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> Does the line number displayed in the mode line update correctly when
 >> you do that and scroll the window?
 >
 > Yes, as before. Should there be a problem now?

Not necessarily.  If you don't see any problems there, the calls in
window_scroll_pixel_based could be possibly removed since that case
should be covered elsewhere.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> Perhaps I should get rid of the internal border code, it's new to the
 >> NS port in Emacs 28.
 >
 > You could definitely make it optional, so that people who'd like
 > faster redisplay could decide whether they are okay with giving up the
 > internal border.

I haven't looked into it but can't running that code be simply
suppressed when no internal border should be drawn anyway?  That is,
when the width is zero which should be the default.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

Does “not necessarily” mean

(a) if I dont’ have the mentioned problem now, I will never see it;

or

(b) I should not be surprised if I see it in three weeks, say.

> Am 15.12.2020 um 08:58 schrieb martin rudalics <rudalics@gmx.at>:
> 
> >> Does the line number displayed in the mode line update correctly when
> >> you do that and scroll the window?
> >
> > Yes, as before. Should there be a problem now?
> 
> Not necessarily.  If you don't see any problems there, the calls in
> window_scroll_pixel_based could be possibly removed since that case
> should be covered elsewhere.
> 
> martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > Does “not necessarily” mean
 >
 > (a) if I dont’ have the mentioned problem now, I will never see it;
 >
 > or
 >
 > (b) I should not be surprised if I see it in three weeks, say.

(a) hopefully.  But note that this is just the isolated problem that
when you scroll the buffer and redisplay has to relocate point in the
buffer in order to make it visible, the current line number doesn't get
updated correctly in the mode line.  As Eli noted elsewhere, there might
be other things that don't get updated correctly.  Ideally, none of
these other things should be affected by scrolling but who knows what
users put into their 'window-scroll-functions' ...

Finally, I doubt that the two 'wset_update_mode_line' calls in
'wset_update_mode_line' are responsible for the flickering you see.  If
they are not, it might make sense to look for the real culprits.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

Just to clarify, despite of the title of this bug, it is not a flickering, but the mouse-wheel scrolling preformance decreases with the number of open frames, in the sense that it becomes more and more sticky.



> Am 15.12.2020 um 14:51 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > Does “not necessarily” mean
> >
> > (a) if I dont’ have the mentioned problem now, I will never see it;
> >
> > or
> >
> > (b) I should not be surprised if I see it in three weeks, say.
> 
> (a) hopefully.  But note that this is just the isolated problem that
> when you scroll the buffer and redisplay has to relocate point in the
> buffer in order to make it visible, the current line number doesn't get
> updated correctly in the mode line.  As Eli noted elsewhere, there might
> be other things that don't get updated correctly.  Ideally, none of
> these other things should be affected by scrolling but who knows what
> users put into their 'window-scroll-functions' ...
> 
> Finally, I doubt that the two 'wset_update_mode_line' calls in
> 'wset_update_mode_line' are responsible for the flickering you see.  If
> they are not, it might make sense to look for the real culprits.
> 
> martin
> 

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > Just to clarify, despite of the title of this bug, it is not a
 > flickering, but the mouse-wheel scrolling preformance decreases with
 > the number of open frames, in the sense that it becomes more and more
 > sticky.

In that case we should consider implementing a variable that updates the
mode lines on one specific frame only.  Does performance not degrade when
you comment out _only_ the two instances of 'wset_update_mode_line' in
'window_scroll_pixel_based'?

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 15 Dec 2020 08:58:59 +0100
> Cc: Alan Third <alan@idiocy.org>, 42406@debbugs.gnu.org
> 
>  >> Does the line number displayed in the mode line update correctly when
>  >> you do that and scroll the window?
>  >
>  > Yes, as before. Should there be a problem now?
> 
> Not necessarily.  If you don't see any problems there, the calls in
> window_scroll_pixel_based could be possibly removed since that case
> should be covered elsewhere.

Sorry, no.  We will not remove those calls without a positive evidence
that they are not needed.  It is not enough to say that someone
doesn't see any adverse effects in his/her use patterns and Emacs
customizations.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> Not necessarily.  If you don't see any problems there, the calls in
 >> window_scroll_pixel_based could be possibly removed since that case
 >> should be covered elsewhere.
 >
 > Sorry, no.  We will not remove those calls without a positive evidence
 > that they are not needed.  It is not enough to say that someone
 > doesn't see any adverse effects in his/her use patterns and Emacs
 > customizations.

Agreed, obviously.  But updating the mode lines on all frames because a
user scrolls a window is pure overkill.  So if all else fails, we could
make such behavior optional.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Tue, Dec 15, 2020 at 08:59:35AM +0100, martin rudalics wrote:
> >> Perhaps I should get rid of the internal border code, it's new to the
> >> NS port in Emacs 28.
> >
> > You could definitely make it optional, so that people who'd like
> > faster redisplay could decide whether they are okay with giving up the
> > internal border.
> 
> I haven't looked into it but can't running that code be simply
> suppressed when no internal border should be drawn anyway?  That is,
> when the width is zero which should be the default.

The default is 2 on the NS port, and on non-GTK X builds it would
appear to be 1.

I'm inclined to just leave it as-is. If people want to try setting it
to zero themselves they can, because as you say it doesn't do anything
if it's 0.
-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 15 Dec 2020 18:14:25 +0100
> 
>  > Sorry, no.  We will not remove those calls without a positive evidence
>  > that they are not needed.  It is not enough to say that someone
>  > doesn't see any adverse effects in his/her use patterns and Emacs
>  > customizations.
> 
> Agreed, obviously.  But updating the mode lines on all frames because a
> user scrolls a window is pure overkill.  So if all else fails, we could
> make such behavior optional.

Patches to make redisplay more fine grained will be welcome, of
course.  But they need careful analysis of which commands and
functions need what parts of the display be redrawn.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> I haven't looked into it but can't running that code be simply
 >> suppressed when no internal border should be drawn anyway?  That is,
 >> when the width is zero which should be the default.
 >
 > The default is 2 on the NS port, and on non-GTK X builds it would
 > appear to be 1.
 >
 > I'm inclined to just leave it as-is. If people want to try setting it
 > to zero themselves they can, because as you say it doesn't do anything
 > if it's 0.

So if Konrad sets the 'internal-border-width' frame parameter to 0 the
slowdown should not happen.  Right?

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

Performance does not degrade when only the two calls of wset_update_mode_line you mentioned are commented out. However, with just commenting out these two instances, I still have a scroll performance problem when scrolling by using the scroll-bars. Could you also identify the instance concerning this?

Thanks, Konrad


> Am 15.12.2020 um 16:20 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > Just to clarify, despite of the title of this bug, it is not a
> > flickering, but the mouse-wheel scrolling preformance decreases with
> > the number of open frames, in the sense that it becomes more and more
> > sticky.
> 
> In that case we should consider implementing a variable that updates the
> mode lines on one specific frame only.  Does performance not degrade when
> you comment out _only_ the two instances of 'wset_update_mode_line' in
> 'window_scroll_pixel_based'?
> 
> martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> Date: Tue, 15 Dec 2020 20:31:19 +0100
> Cc: Alan Third <alan@idiocy.org>, 42406@debbugs.gnu.org
> 
> Performance does not degrade when only the two calls of wset_update_mode_line you mentioned are commented out. However, with just commenting out these two instances, I still have a scroll performance problem when scrolling by using the scroll-bars. Could you also identify the instance concerning this?

Please be more specific: how do you scroll with the scroll bars, and
what kind of performance problem you experience as result of that?

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Tue, Dec 15, 2020 at 07:54:49PM +0100, martin rudalics wrote:
> >> I haven't looked into it but can't running that code be simply
> >> suppressed when no internal border should be drawn anyway?  That is,
> >> when the width is zero which should be the default.
> >
> > The default is 2 on the NS port, and on non-GTK X builds it would
> > appear to be 1.
> >
> > I'm inclined to just leave it as-is. If people want to try setting it
> > to zero themselves they can, because as you say it doesn't do anything
> > if it's 0.
> 
> So if Konrad sets the 'internal-border-width' frame parameter to 0 the
> slowdown should not happen.  Right?

The cursor is still redrawn, so it may make no difference.

The NS port has two drawing paths, on older macs and Gnustep it draws
and the screen is updated piecemeal. On newer macs it draws to an
offscreen buffer and then that buffer is drawn to the screen. Drawing
the buffer to the screen is very slow.

It depends what Konrad's system is doing whether it will make much
difference, but I suspect he's using the off-screen buffer path so the
cursor redraw will force the whole frame update anyway.

-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

Just using the mouse, moving the vertical scroll-bars up and down. As with mouse-wheel scrolling, performance decreases with the number of open frames, in the sense that scrolling becomes more and more sticky.



> Am 15.12.2020 um 20:45 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
>> Date: Tue, 15 Dec 2020 20:31:19 +0100
>> Cc: Alan Third <alan@idiocy.org>, 42406@debbugs.gnu.org
>> 
>> Performance does not degrade when only the two calls of wset_update_mode_line you mentioned are commented out. However, with just commenting out these two instances, I still have a scroll performance problem when scrolling by using the scroll-bars. Could you also identify the instance concerning this?
> 
> Please be more specific: how do you scroll with the scroll bars, and
> what kind of performance problem you experience as result of that?

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> Date: Tue, 15 Dec 2020 20:52:25 +0100
> Cc: martin rudalics <rudalics@gmx.at>,
>  Alan Third <alan@idiocy.org>,
>  42406@debbugs.gnu.org
> 
> Just using the mouse, moving the vertical scroll-bars up and down. As with mouse-wheel scrolling, performance decreases with the number of open frames, in the sense that scrolling becomes more and more sticky.

As long as you invoke scrolling commands (and that's what the scroll
bar eventually does in Emacs), you will always have the same problem:
scrolling commands cause Emacs redraw all the frames.  If the NS port
does that inefficiently, you will see performance hit.  The general
assumption in the Emacs display engine is that the absolute majority
of the frame's display will not actually be redrawn on the glass,
because Emacs knows they don't need to.  If the NS port violates this,
or if it is too slow to redraw the frame decorations that Emacs cannot
control directly (i.e. it cannot know whether they need to be
redrawn), then the performance you see will be worse than expected.

How many frames do you need to create before just dragging the
scroll-bar thumb slows down enough to be tangible? 2? 5? 10? more?

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

5 frames

> Am 15.12.2020 um 21:05 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
>> Date: Tue, 15 Dec 2020 20:52:25 +0100
>> Cc: martin rudalics <rudalics@gmx.at>,
>> Alan Third <alan@idiocy.org>,
>> 42406@debbugs.gnu.org
>> 
>> Just using the mouse, moving the vertical scroll-bars up and down. As with mouse-wheel scrolling, performance decreases with the number of open frames, in the sense that scrolling becomes more and more sticky.
> 
> As long as you invoke scrolling commands (and that's what the scroll
> bar eventually does in Emacs), you will always have the same problem:
> scrolling commands cause Emacs redraw all the frames.  If the NS port
> does that inefficiently, you will see performance hit.  The general
> assumption in the Emacs display engine is that the absolute majority
> of the frame's display will not actually be redrawn on the glass,
> because Emacs knows they don't need to.  If the NS port violates this,
> or if it is too slow to redraw the frame decorations that Emacs cannot
> control directly (i.e. it cannot know whether they need to be
> redrawn), then the performance you see will be worse than expected.
> 
> How many frames do you need to create before just dragging the
> scroll-bar thumb slows down enough to be tangible? 2? 5? 10? more?

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> Date: Tue, 15 Dec 2020 21:12:24 +0100
> Cc: martin rudalics <rudalics@gmx.at>,
>  alan@idiocy.org,
>  42406@debbugs.gnu.org
> 
> 5 frames

Here on MS-Windows, I see no difference between 2 frames and 5.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > Performance does not degrade when only the two calls of
 > wset_update_mode_line you mentioned are commented out. However, with
 > just commenting out these two instances, I still have a scroll
 > performance problem when scrolling by using the scroll-bars. Could you
 > also identify the instance concerning this?

I forgot how Emacs precisely handles that.  Maybe Eli can tell.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> So if Konrad sets the 'internal-border-width' frame parameter to 0 the
 >> slowdown should not happen.  Right?
 >
 > The cursor is still redrawn, so it may make no difference.

Because of the update mode lines flag?

 > The NS port has two drawing paths, on older macs and Gnustep it draws
 > and the screen is updated piecemeal. On newer macs it draws to an
 > offscreen buffer and then that buffer is drawn to the screen. Drawing
 > the buffer to the screen is very slow.
 >
 > It depends what Konrad's system is doing whether it will make much
 > difference, but I suspect he's using the off-screen buffer path so the
 > cursor redraw will force the whole frame update anyway.

Konrad says that when he suppresses setting the update mode lines flags
he sees no delays.  But apparently his cursor is still redrawn correctly
because he has seen no problems.  I'm just asking myself whether we talk
about the same problem here or only related ones.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > As long as you invoke scrolling commands (and that's what the scroll
 > bar eventually does in Emacs), you will always have the same problem:
 > scrolling commands cause Emacs redraw all the frames.

Because it has to update mode lines or are there any other reasons?

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 16 Dec 2020 09:46:59 +0100
> 
>  > As long as you invoke scrolling commands (and that's what the scroll
>  > bar eventually does in Emacs), you will always have the same problem:
>  > scrolling commands cause Emacs redraw all the frames.
> 
> Because it has to update mode lines or are there any other reasons?

Mode lines, header lines, and frame title.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 16 Dec 2020 09:46:18 +0100
> Cc: Alan Third <alan@idiocy.org>, 42406@debbugs.gnu.org
> 
>  > Performance does not degrade when only the two calls of
>  > wset_update_mode_line you mentioned are commented out. However, with
>  > just commenting out these two instances, I still have a scroll
>  > performance problem when scrolling by using the scroll-bars. Could you
>  > also identify the instance concerning this?
> 
> I forgot how Emacs precisely handles that.  Maybe Eli can tell.

See scroll-bar-toolkit-scroll.  Basically, it calls
scroll-up/scroll-down.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >>   > Performance does not degrade when only the two calls of
 >>   > wset_update_mode_line you mentioned are commented out. However, with
 >>   > just commenting out these two instances, I still have a scroll
 >>   > performance problem when scrolling by using the scroll-bars. Could you
 >>   > also identify the instance concerning this?
 >>
 >> I forgot how Emacs precisely handles that.  Maybe Eli can tell.
 >
 > See scroll-bar-toolkit-scroll.  Basically, it calls
 > scroll-up/scroll-down.

Then something else must come into play here.  I don't see where
'scroll-bar-toolkit-scroll' forces a mode line update.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 16 Dec 2020 17:53:37 +0100
> 
>  >> I forgot how Emacs precisely handles that.  Maybe Eli can tell.
>  >
>  > See scroll-bar-toolkit-scroll.  Basically, it calls
>  > scroll-up/scroll-down.
> 
> Then something else must come into play here.  I don't see where
> 'scroll-bar-toolkit-scroll' forces a mode line update.

AFAIR, scroll-up does.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> Then something else must come into play here.  I don't see where
 >> 'scroll-bar-toolkit-scroll' forces a mode line update.
 >
 > AFAIR, scroll-up does.

'scroll-up' runs scroll_command and nothing else.  And if you mean the
instances in window_scroll_pixel_based, then these are the ones Konrad
removed in his Emacs.  Maybe the NS port does something completely
different here ...

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 16 Dec 2020 19:51:39 +0100
> 
>  >> Then something else must come into play here.  I don't see where
>  >> 'scroll-bar-toolkit-scroll' forces a mode line update.
>  >
>  > AFAIR, scroll-up does.
> 
> 'scroll-up' runs scroll_command and nothing else.

Yes.  And scroll_command calls window_scroll, and that calls
window_scroll_pixel_based, where we have these wset_update_mode_line
calls about which you asked.  Or what am I missing?

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

To clarify my observation:  If I comment out just the two calls to wset_update_mode_line that are in window_scroll_pixel_based, then the mouse wheel scrolling problem with multiple frames goes away, but the problem with scrolling via the scroll bars remains; if I comment out all five calls to wset_update_mode which are in window.c, then in addition the scroll-bar problem goes away (with multiple frames). I just wanted to know whether Martin has an idea which of the remaining three calls (when they are not out-commented) could be responsible for the scroll-bar problem.
 



> Am 16.12.2020 um 19:51 schrieb martin rudalics <rudalics@gmx.at>:
> 
> >> Then something else must come into play here.  I don't see where
> >> 'scroll-bar-toolkit-scroll' forces a mode line update.
> >
> > AFAIR, scroll-up does.
> 
> 'scroll-up' runs scroll_command and nothing else.  And if you mean the
> instances in window_scroll_pixel_based, then these are the ones Konrad
> removed in his Emacs.  Maybe the NS port does something completely
> different here ...
> 
> martin

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Tue, Dec 15, 2020 at 03:06:03PM +0100, Konrad Podczeck wrote:
> Just to clarify, despite of the title of this bug, it is not a
> flickering, but the mouse-wheel scrolling preformance decreases with
> the number of open frames, in the sense that it becomes more and
> more sticky.

I don't think the attached patch will fix this, but it may improve
things a little. Can you please try it?

-- 
Alan Third

[-- Attachment #2: 0001-Improve-drawing-performance-on-macOS.patch --]
[-- Type: text/plain, Size: 7442 bytes --]

From d6951394d803c36c9dafc8c941b7b40033851ec4 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Wed, 16 Dec 2020 21:12:04 +0000
Subject: [PATCH] Improve drawing performance on macOS

* configure.ac: Require IOSurface framework.
* src/nsterm.h: Add new definitions.
* src/nsterm.m (ns_update_end):
(ns_unfocus): Use new unfocusDrawingBuffer method.
(ns_draw_window_cursor): Move ns_focus to before we set colors.
([EmacsView dealloc]): Release the new IOSurface.
([EmacsView createDrawingBuffer]): Use a new IOSurface to draw to
and point a CGBitmapContext to it.
([EmacsView focusOnDrawingBuffer]): Lock the IOSurface for drawing.
([EmacsView unfocusDrawingBuffer]): New function.
([EmacsView updateLayer]): Removed as no longer needed.
---
 configure.ac |  2 +-
 src/nsterm.h | 13 +++++++++
 src/nsterm.m | 75 +++++++++++++++++++++++++++++++++++++++-------------
 3 files changed, 70 insertions(+), 20 deletions(-)

diff --git a/configure.ac b/configure.ac
index 888b415148..88afd7348e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5491,7 +5491,7 @@ AC_DEFUN
    if test "$HAVE_NS" = "yes"; then
      libs_nsgui="-framework AppKit"
      if test "$NS_IMPL_COCOA" = "yes"; then
-        libs_nsgui="$libs_nsgui -framework IOKit -framework Carbon"
+        libs_nsgui="$libs_nsgui -framework IOKit -framework Carbon -framework IOSurface"
      fi
    else
      libs_nsgui=
diff --git a/src/nsterm.h b/src/nsterm.h
index f292993d8f..6c456d3724 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -435,6 +435,7 @@ #define NS_DRAW_TO_BUFFER 1
    BOOL fs_is_native;
    BOOL in_fullscreen_transition;
 #ifdef NS_DRAW_TO_BUFFER
+   IOSurfaceRef surface;
    CGContextRef drawingBuffer;
 #endif
 @public
@@ -478,6 +479,7 @@ #define NS_DRAW_TO_BUFFER 1
 
 #ifdef NS_DRAW_TO_BUFFER
 - (void)focusOnDrawingBuffer;
+- (void)unfocusDrawingBuffer;
 - (void)createDrawingBuffer;
 #endif
 - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect;
@@ -729,6 +731,17 @@ #define NS_DRAW_TO_BUFFER 1
 @end
 #endif
 
+/* This is a private API, but it seems we need it to force the CALayer
+   to recognise that the IOSurface has been updated.
+
+   I believe using it will prevent Emacs from ever making it into the
+   Apple App Store.  😎 */
+#ifdef NS_DRAW_TO_BUFFER
+@interface CALayer (Private)
+- (void)setContentsChanged;
+@end
+#endif
+
 #endif  /* __OBJC__ */
 
 
diff --git a/src/nsterm.m b/src/nsterm.m
index 7972fa4dab..8241630a50 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -72,6 +72,10 @@ Updated by Christian Limpach (chris@nice.ch)
 #include <Carbon/Carbon.h>
 #endif
 
+#ifdef NS_DRAW_TO_BUFFER
+#include <IOSurface/IOSurface.h>
+#endif
+
 static EmacsMenu *dockMenu;
 #ifdef NS_IMPL_COCOA
 static EmacsMenu *mainMenu;
@@ -1165,7 +1169,7 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
   if ([FRAME_NS_VIEW (f) wantsUpdateLayer])
     {
 #endif
-      [NSGraphicsContext setCurrentContext:nil];
+      [FRAME_NS_VIEW (f) unfocusDrawingBuffer];
 #if MAC_OS_X_VERSION_MIN_REQUIRED < 101400
     }
   else
@@ -1273,6 +1277,8 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
   if ([FRAME_NS_VIEW (f) wantsUpdateLayer])
     {
 #endif
+      if (! ns_updating_frame)
+        [FRAME_NS_VIEW (f) unfocusDrawingBuffer];
       [FRAME_NS_VIEW (f) setNeedsDisplay:YES];
 #if MAC_OS_X_VERSION_MIN_REQUIRED < 101400
     }
@@ -3404,6 +3410,8 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
   /* Prevent the cursor from being drawn outside the text area.  */
   r = NSIntersectionRect (r, ns_row_rect (w, glyph_row, TEXT_AREA));
 
+  ns_focus (f, &r, 1);
+
   face = FACE_FROM_ID_OR_NULL (f, phys_cursor_glyph->face_id);
   if (face && NS_FACE_BACKGROUND (face)
       == ns_index_color (FRAME_CURSOR_COLOR (f), f))
@@ -3414,8 +3422,6 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
   else
     [FRAME_CURSOR_COLOR (f) set];
 
-  ns_focus (f, &r, 1);
-
   switch (cursor_type)
     {
     case DEFAULT_CURSOR:
@@ -6369,6 +6375,7 @@ - (void)dealloc
 
 #ifdef NS_DRAW_TO_BUFFER
   CGContextRelease (drawingBuffer);
+  CFRelease (surface);
 #endif
 
   [toolbar release];
@@ -8427,23 +8434,49 @@ - (void)createDrawingBuffer
   CGColorSpaceRef colorSpace = [[[self window] colorSpace] CGColorSpace];
   CGFloat scale = [[self window] backingScaleFactor];
   NSRect frame = [self frame];
+  int width, height, bytesPerRow;
 
   if (drawingBuffer != nil)
-    CGContextRelease (drawingBuffer);
+    {
+      CGContextRelease (drawingBuffer);
+      CFRelease (surface);
+    }
+
+  width = NSWidth (frame) * scale;
+  height = NSHeight (frame) * scale;
+  bytesPerRow = IOSurfaceAlignProperty (kIOSurfaceBytesPerRow, width * 4);
 
-  drawingBuffer = CGBitmapContextCreate (nil, NSWidth (frame) * scale, NSHeight (frame) * scale,
-                                         8, 0, colorSpace,
-                                         kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host);
+  surface = IOSurfaceCreate
+    ((CFDictionaryRef)@{(id)kIOSurfaceWidth:[NSNumber numberWithInt:width],
+        (id)kIOSurfaceHeight:[NSNumber numberWithInt:height],
+        (id)kIOSurfaceBytesPerRow:[NSNumber numberWithInt:bytesPerRow],
+        (id)kIOSurfaceBytesPerElement:[NSNumber numberWithInt:4],
+        (id)kIOSurfacePixelFormat:[NSNumber numberWithInt:kCVPixelFormatType_32RGBA]});
+
+  drawingBuffer = CGBitmapContextCreate (IOSurfaceGetBaseAddress (surface),
+                                         IOSurfaceGetWidth (surface),
+                                         IOSurfaceGetHeight (surface),
+                                         8,
+                                         IOSurfaceGetBytesPerRow (surface),
+                                         colorSpace,
+                                         IOSurfaceGetPixelFormat (surface));
 
   /* This fixes the scale to match the backing scale factor, and flips the image.  */
-  CGContextTranslateCTM(drawingBuffer, 0, NSHeight (frame) * scale);
+  CGContextTranslateCTM(drawingBuffer, 0, IOSurfaceGetHeight (surface));
   CGContextScaleCTM(drawingBuffer, scale, -scale);
+
+  [[self layer] setContents:(id)surface];
 }
 
 
 - (void)focusOnDrawingBuffer
 {
-  NSTRACE ("EmacsView focusOnDrawingBuffer]");
+  IOReturn lockStatus;
+
+  NSTRACE ("[EmacsView focusOnDrawingBuffer]");
+
+  if ((lockStatus = IOSurfaceLock (surface, 0, nil)) != kIOReturnSuccess)
+    NSLog (@"Failed to lock surface: %x", lockStatus);
 
   NSGraphicsContext *buf =
     [NSGraphicsContext
@@ -8453,6 +8486,20 @@ - (void)focusOnDrawingBuffer
 }
 
 
+- (void)unfocusDrawingBuffer
+{
+  IOReturn lockStatus;
+
+  NSTRACE ("[EmacsView unfocusDrawingBuffer]");
+
+  [NSGraphicsContext setCurrentContext:nil];
+  if ((lockStatus = IOSurfaceUnlock (surface, 0, nil)) != kIOReturnSuccess)
+    NSLog (@"Failed to unlock surface: %x", lockStatus);
+
+  [[self layer] setContentsChanged];
+}
+
+
 - (void)windowDidChangeBackingProperties:(NSNotification *)notification
   /* Update the drawing buffer when the backing properties change.  */
 {
@@ -8541,16 +8588,6 @@ - (BOOL)wantsUpdateLayer
   /* Running on macOS 10.14 or above.  */
   return YES;
 }
-
-
-- (void)updateLayer
-{
-  NSTRACE ("[EmacsView updateLayer]");
-
-  CGImageRef contentsImage = CGBitmapContextCreateImage(drawingBuffer);
-  [[self layer] setContents:(id)contentsImage];
-  CGImageRelease(contentsImage);
-}
 #endif
 
 
-- 
2.29.2

bug#42406: Mouse-wheel scrolling can be flickering

[Alan Third]

On Wed, Dec 16, 2020 at 09:46:48AM +0100, martin rudalics wrote:
> >> So if Konrad sets the 'internal-border-width' frame parameter to 0 the
> >> slowdown should not happen.  Right?
> >
> > The cursor is still redrawn, so it may make no difference.
> 
> Because of the update mode lines flag?

I believe so, yes. When it's set, as far as I can see from looking at
the code we call clear_under_internal_border and update_frame, which
ultimately causes the cursor to be redrawn.

-- 
Alan Third

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

With this patch, toolbar, frame-title, menu and scroll-bars display correctly, but the text-area of a frame is just white, i.e., no text appears.

Konrad
> Am 16.12.2020 um 22:31 schrieb Alan Third <alan@idiocy.org>:
> 
> On Tue, Dec 15, 2020 at 03:06:03PM +0100, Konrad Podczeck wrote:
>> Just to clarify, despite of the title of this bug, it is not a
>> flickering, but the mouse-wheel scrolling preformance decreases with
>> the number of open frames, in the sense that it becomes more and
>> more sticky.
> 
> I don't think the attached patch will fix this, but it may improve
> things a little. Can you please try it?
> 
> -- 
> Alan Third
> <0001-Improve-drawing-performance-on-macOS.patch>

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >>   >> Then something else must come into play here.  I don't see where
 >>   >> 'scroll-bar-toolkit-scroll' forces a mode line update.
 >>   >
 >>   > AFAIR, scroll-up does.
 >>
 >> 'scroll-up' runs scroll_command and nothing else.
 >
 > Yes.  And scroll_command calls window_scroll, and that calls
 > window_scroll_pixel_based, where we have these wset_update_mode_line
 > calls about which you asked.  Or what am I missing?

The rest of my message where I said that

 >> And if you mean the
 >> instances in window_scroll_pixel_based, then these are the ones Konrad
 >> removed in his Emacs.

but probably my formulation was not comprehensible enough.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > To clarify my observation: If I comment out just the two calls to
 > wset_update_mode_line that are in window_scroll_pixel_based, then the
 > mouse wheel scrolling problem with multiple frames goes away, but the
 > problem with scrolling via the scroll bars remains; if I comment out
 > all five calls to wset_update_mode which are in window.c, then in
 > addition the scroll-bar problem goes away (with multiple frames). I
 > just wanted to know whether Martin has an idea which of the remaining
 > three calls (when they are not out-commented) could be responsible for
 > the scroll-bar problem.

I suppose it happens via 'scroll-bar-toolkit-scroll' calling
'scroll-bar-drag-1' calling 'set-window-start' so commenting out the

   wset_update_mode_line (w);
   /* Bug#15957.  */

occurrence in Fset_window_start should cut it.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

> Am 17.12.2020 um 08:29 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > To clarify my observation: If I comment out just the two calls to
> > wset_update_mode_line that are in window_scroll_pixel_based, then the
> > mouse wheel scrolling problem with multiple frames goes away, but the
> > problem with scrolling via the scroll bars remains; if I comment out
> > all five calls to wset_update_mode which are in window.c, then in
> > addition the scroll-bar problem goes away (with multiple frames). I
> > just wanted to know whether Martin has an idea which of the remaining
> > three calls (when they are not out-commented) could be responsible for
> > the scroll-bar problem.
> 
> I suppose it happens via 'scroll-bar-toolkit-scroll' calling
> 'scroll-bar-drag-1' calling 'set-window-start' so commenting out the
> 
>  wset_update_mode_line (w);
>  /* Bug#15957.  */
> 
> occurrence in Fset_window_start should cut it.


Thanks! This did the job. Is there a way to exactly test whether the (now) three out-commenting of wset_update_mode_line are really as harmless at they appear? Could there be other scrolling problems, say by scrolling via keys?

Konrad 

> 
> martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > Thanks! This did the job. Is there a way to exactly test whether the
 > (now) three out-commenting of wset_update_mode_line are really as
 > harmless at they appear? Could there be other scrolling problems, say
 > by scrolling via keys?

First of all I would replace these

   wset_update_mode_line (w);

with

   w->update_mode_line = true;

This way you make sure that the mode line does get updated whenever the
scrolled window is on the selected frame.  Then problems should occur
only when you either use the mouse wheel or the scroll bar on a
non-selected frame.  In that case, the line number of the associated
window might not get updated until its frame gets selected.

The (IMHO) right fix would be to have wset_update_mode_line add the
frame containing the scrolled window to a list of frames the next
redisplay should investigate.  This might still fail when say frame A is
selected, a window on frame B was scrolled and the title format of frame
C wants to display the line number of that window.  I wouldn't care
about such pathological cases but maybe someone does.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Alan Third <alan@idiocy.org>,
>  42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 17 Dec 2020 08:29:48 +0100
> 
>  > To clarify my observation: If I comment out just the two calls to
>  > wset_update_mode_line that are in window_scroll_pixel_based, then the
>  > mouse wheel scrolling problem with multiple frames goes away, but the
>  > problem with scrolling via the scroll bars remains; if I comment out
>  > all five calls to wset_update_mode which are in window.c, then in
>  > addition the scroll-bar problem goes away (with multiple frames). I
>  > just wanted to know whether Martin has an idea which of the remaining
>  > three calls (when they are not out-commented) could be responsible for
>  > the scroll-bar problem.
> 
> I suppose it happens via 'scroll-bar-toolkit-scroll' calling
> 'scroll-bar-drag-1' calling 'set-window-start' so commenting out the
> 
>    wset_update_mode_line (w);
>    /* Bug#15957.  */
> 
> occurrence in Fset_window_start should cut it.

set-window-start is how Lisp programs tell the display engine to
scroll the display.  So if we agree that scrolling should trigger
update of the frame's elements other than the selected window, then
these calls to wset_update_mode_line are necessary and cannot be
removed.

As I said previously, patches are welcome to make the decision of what
exactly needs to be redrawn more fine-grained than the current "either
just the selected window or all the windows on all the frames" method.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Alan Third <alan@idiocy.org>,
>  42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 17 Dec 2020 14:21:48 +0100
> 
> The (IMHO) right fix would be to have wset_update_mode_line add the
> frame containing the scrolled window to a list of frames the next
> redisplay should investigate.

That won't work without also changing redisplay_internal to consider
such a list.  It currently knows about just 2 alternatives: either
consider only the selected window on the selected frame, or all
windows on all frames -- and only the second option considers
non-window aspects (such as the frame title or menu bar) of the
selected frame.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > set-window-start is how Lisp programs tell the display engine to
 > scroll the display.  So if we agree that scrolling should trigger
 > update of the frame's elements other than the selected window,

Personally I don't agree but happily leave this decision to others.

 > then
 > these calls to wset_update_mode_line are necessary and cannot be
 > removed.
 >
 > As I said previously, patches are welcome to make the decision of what
 > exactly needs to be redrawn more fine-grained than the current "either
 > just the selected window or all the windows on all the frames" method.

We talk here about a workaround Konrad would use in his personal builds
to avoid that scrolling a window slows down his system until something
better is available.  Or what would you do in his place?

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > That won't work without also changing redisplay_internal to consider
 > such a list.  It currently knows about just 2 alternatives: either
 > consider only the selected window on the selected frame, or all
 > windows on all frames -- and only the second option considers
 > non-window aspects (such as the frame title or menu bar) of the
 > selected frame.

The part mostly affected would be

   if (consider_all_windows_p)
     {
       FOR_EACH_FRAME (tail, frame)
	XFRAME (frame)->updated_p = false;

because windows_or_buffers_changed should probably become either a list
too or redisplay would simply scan all windows and act when it finds a
window whose w->update_mode_line or w->changed flag is true.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Konrad Podczeck]

Let me reply that,  with the three critical instances of  wset_updated_mode_line just out-commented, when I scroll in a frame _with_ input focus, then the mode line is always correctly updated. If I scroll in a frame without input focus, then at least the percentage is always updated, and the line-number is update as soon as the (hollow) cursor reaches the top or the bottom of the range of text shown in the frame. In any case, with global-line-numbers-mode on, is there a situation where, in practice,  one needs to look at the line numbers as shown in the mode line?


> Am 17.12.2020 um 14:21 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > Thanks! This did the job. Is there a way to exactly test whether the
> > (now) three out-commenting of wset_update_mode_line are really as
> > harmless at they appear? Could there be other scrolling problems, say
> > by scrolling via keys?
> 
> First of all I would replace these
> 
>  wset_update_mode_line (w);
> 
> with
> 
>  w->update_mode_line = true;
> 
> This way you make sure that the mode line does get updated whenever the
> scrolled window is on the selected frame.  Then problems should occur
> only when you either use the mouse wheel or the scroll bar on a
> non-selected frame.  In that case, the line number of the associated
> window might not get updated until its frame gets selected.
> 
> The (IMHO) right fix would be to have wset_update_mode_line add the
> frame containing the scrolled window to a list of frames the next
> redisplay should investigate.  This might still fail when say frame A is
> selected, a window on frame B was scrolled and the title format of frame
> C wants to display the line number of that window.  I wouldn't care
> about such pathological cases but maybe someone does.
> 
> martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 17 Dec 2020 16:13:37 +0100
> 
>  > As I said previously, patches are welcome to make the decision of what
>  > exactly needs to be redrawn more fine-grained than the current "either
>  > just the selected window or all the windows on all the frames" method.
> 
> We talk here about a workaround Konrad would use in his personal builds
> to avoid that scrolling a window slows down his system until something
> better is available.  Or what would you do in his place?

In one's personal build one could use whatever one likes.  I only care
to make it clear that this is not a solution we can adopt for Emacs in
general.

(FWIW, I don't see on my system any slowdown with 5 frames, like
Konrad does.  So this could very well be NS-specific.)

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 17 Dec 2020 16:13:53 +0100
> 
>  > That won't work without also changing redisplay_internal to consider
>  > such a list.  It currently knows about just 2 alternatives: either
>  > consider only the selected window on the selected frame, or all
>  > windows on all frames -- and only the second option considers
>  > non-window aspects (such as the frame title or menu bar) of the
>  > selected frame.
> 
> The part mostly affected would be
> 
>    if (consider_all_windows_p)
>      {
>        FOR_EACH_FRAME (tail, frame)
> 	XFRAME (frame)->updated_p = false;

You mean, it will not affect the following FOR_EACH_FRAME loop?  If
so, I don't think I follow.

> because windows_or_buffers_changed should probably become either a list
> too or redisplay would simply scan all windows and act when it finds a
> window whose w->update_mode_line or w->changed flag is true.

I don't think windows are the problem: Emacs knows very well which
window(s) actually need(s) to be redisplayed and redrawn.  The problem
is with frame decorations that don't belong to any window: there we
rely on the OS and the WM to refrain from redrawing stuff unless
really needed.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > Let me reply that, with the three critical instances of
 > wset_updated_mode_line just out-commented, when I scroll in a frame
 > _with_ input focus, then the mode line is always correctly updated.

Because scrolling can change lots of other things in the selected window
so this is probably expected.

 > If
 > I scroll in a frame without input focus, then at least the percentage
 > is always updated, and the line-number is update as soon as the
 > (hollow) cursor reaches the top or the bottom of the range of text
 > shown in the frame. In any case, with global-line-numbers-mode on, is
 > there a situation where, in practice, one needs to look at the line
 > numbers as shown in the mode line?

I hardly ever look so I can't tell.  But doing the substitutions I
suggested earlier can hardly harm IMO.  And if they harm, then we'd yet
have another issue to investigate.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> Date: Thu, 17 Dec 2020 17:40:30 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  Alan Third <alan@idiocy.org>,
>  42406@debbugs.gnu.org
> 
> Let me reply that,  with the three critical instances of  wset_updated_mode_line just out-commented, when I scroll in a frame _with_ input focus, then the mode line is always correctly updated. If I scroll in a frame without input focus, then at least the percentage is always updated, and the line-number is update as soon as the (hollow) cursor reaches the top or the bottom of the range of text shown in the frame. In any case, with global-line-numbers-mode on, is there a situation where, in practice,  one needs to look at the line numbers as shown in the mode line?

Only you can answer that question, because only you know what is and
isn't important on display for your use patterns.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 > (FWIW, I don't see on my system any slowdown with 5 frames, like
 > Konrad does.  So this could very well be NS-specific.

It apparently is.  Otherwise, you would have fixed that long ago.

 > )

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> The part mostly affected would be
 >>
 >>     if (consider_all_windows_p)
 >>       {
 >>         FOR_EACH_FRAME (tail, frame)
 >> 	XFRAME (frame)->updated_p = false;
 >
 > You mean, it will not affect the following FOR_EACH_FRAME loop?  If
 > so, I don't think I follow.

It would affect it in the sense that not necessarily all frames are
considered.  But you sketched that already in your TODO entry.

 >> because windows_or_buffers_changed should probably become either a list
 >> too or redisplay would simply scan all windows and act when it finds a
 >> window whose w->update_mode_line or w->changed flag is true.
 >
 > I don't think windows are the problem: Emacs knows very well which
 > window(s) actually need(s) to be redisplayed and redrawn.

In the case at hand Emacs relies on redisplaying all frames when
scrolling a window that is not on the selected frame in order to
correctly reflect the change in the scrolled window's mode line.

 > The problem
 > is with frame decorations that don't belong to any window: there we
 > rely on the OS and the WM to refrain from redrawing stuff unless
 > really needed.

IIUC windows_or_buffers_changed affects frames as well.  For example, I
have no idea why making a frame (in)visible should redisplay all other
frames while moving a frame on the screen apparently does not.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

> I think the issue is clear: mouse-scroll calls scrolling commands, and
> all of the scrolling commands set update_mode_lines.  Why they do that
> is explained by the comment in wset_update_mode_line:
>
>   /* If this window is the selected window on its frame, set the
>      global variable update_mode_lines, so that gui_consider_frame_title
>      will consider this frame's title for redisplay.  */

This comment makes sense in `wset_update_mode_line` because that
function is for all cases where the "mode line / frame title" might need
to be updated.

But in the present case, the only change is the w->start
an the position of point: these are important enough to need to update
the mode line (for the column&line number), but I don't think these are
important enough to justify setting `update_mode_lines` to 42:
not only other frames can't be affected, but even the current frame's
title should basically never be affected either because it would be very
unusual to have the line/column number as part of the frame title.

The redisplay code does not guarantee that the mode-lines and
frame-titles will always be fully automatically kept up to date: we do
a good effort to keep it updated automatically, but there are various
cases where we give up and require ELisp code to call
`force-mode-line-update` explicitly.

We could decide that line/column numbers in frame titles fall
into that category of things we won't always automatically update.

This said, a better fix would be to make it so `wset_update_mode_line`
only causes the affected frame to be redrawn rather than all frames.
The patch below should do that.
Could you test it and see if the performance is good?

[ It can't be installed as-is: instead of `2` it should use the constant
  `REDISPLAY_SOME`, but that requires moving the code around.  ]


        Stefan


diff --git a/src/window.c b/src/window.c
index bcc989b5a7..1e9f137cd6 100644
--- a/src/window.c
+++ b/src/window.c
@@ -224,7 +224,10 @@ wset_update_mode_line (struct window *w)
   Lisp_Object fselected_window = XFRAME (WINDOW_FRAME (w))->selected_window;
 
   if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
-    update_mode_lines = 42;
+    {
+      update_mode_lines = 2;
+      fset_redisplay (XFRAME (WINDOW_FRAME (w)));
+    }
   else
     w->update_mode_line = true;
 }

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 17 Dec 2020 18:34:42 +0100
> 
>  > I don't think windows are the problem: Emacs knows very well which
>  > window(s) actually need(s) to be redisplayed and redrawn.
> 
> In the case at hand Emacs relies on redisplaying all frames when
> scrolling a window that is not on the selected frame in order to
> correctly reflect the change in the scrolled window's mode line.

That's not my understanding.  My understanding is that the user
scrolls the _selected_ window, because otherwise wset_update_mode_line
doesn't set update_mode_lines:

  static void
  wset_update_mode_line (struct window *w)
  {
    /* If this window is the selected window on its frame, set the
       global variable update_mode_lines, so that gui_consider_frame_title
       will consider this frame's title for redisplay.  */
    Lisp_Object fselected_window = XFRAME (WINDOW_FRAME (w))->selected_window;

    if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
      update_mode_lines = 42;
    else
      w->update_mode_line = true;
  }


> IIUC windows_or_buffers_changed affects frames as well.  For example, I
> have no idea why making a frame (in)visible should redisplay all other
> frames while moving a frame on the screen apparently does not.

That's commented out now, although the comment seems to hint on the
reason.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alan Third <alan@idiocy.org>,  konrad.podczeck@univie.ac.at,
>   42406@debbugs.gnu.org
> Date: Thu, 17 Dec 2020 12:47:17 -0500
> 
> > I think the issue is clear: mouse-scroll calls scrolling commands, and
> > all of the scrolling commands set update_mode_lines.  Why they do that
> > is explained by the comment in wset_update_mode_line:
> >
> >   /* If this window is the selected window on its frame, set the
> >      global variable update_mode_lines, so that gui_consider_frame_title
> >      will consider this frame's title for redisplay.  */
> 
> This comment makes sense in `wset_update_mode_line` because that
> function is for all cases where the "mode line / frame title" might need
> to be updated.
> 
> But in the present case, the only change is the w->start
> an the position of point: these are important enough to need to update
> the mode line (for the column&line number), but I don't think these are
> important enough to justify setting `update_mode_lines` to 42:
> not only other frames can't be affected, but even the current frame's
> title should basically never be affected either because it would be very
> unusual to have the line/column number as part of the frame title.

"Unusual" doesn't mean "unsupported".  For better or for worse, we
have documentation that is our contract with the users, and we cannot
unilaterally bail out of it, certainly not because the NS port is too
slow in updating the frame titles of 5 frames.

> The redisplay code does not guarantee that the mode-lines and
> frame-titles will always be fully automatically kept up to date:

Oh, yes, it does.  When that doesn't happen, it's a bug we need to
fix.  We just had something like this several months ago, where some
Lisp changed the face of a mode line in a way that required a very
thorough redisplay (because the height of the mode line changed
significantly).

> we do a good effort to keep it updated automatically, but there are
> various cases where we give up and require ELisp code to call
> `force-mode-line-update` explicitly.

force-mode-line-update should only be needed when changes in the mode
line are displayed in the middle of running Lisp code.  Anything else
is most probably a bug.

> We could decide that line/column numbers in frame titles fall
> into that category of things we won't always automatically update.
> 
> This said, a better fix would be to make it so `wset_update_mode_line`
> only causes the affected frame to be redrawn rather than all frames.
> The patch below should do that.
> Could you test it and see if the performance is good?

FWIW, I'm against such "fixes".  The current mix of frame-specific,
window-specific, and global flags is already a complex mess, where it
is extremely hard to understand which one of these should or does
trigger redrawing of something somewhere.  Adding some "assumed" logic
on top of that which is not really backed up by any clear path in the
code, but is just something we implicitly believe should happen, just
makes this mess less maintainable.

We should stop lumping heuristics one on top another, and instead
redesign this from scratch and make sure that every flag we set is
acted upon as intended, and only in situations we intend them to be
acted upon.  E.g., we should be able to set f->redisplay to a value
that means "update only the frame title".

> [ It can't be installed as-is: instead of `2` it should use the constant
>   `REDISPLAY_SOME`, but that requires moving the code around.  ]

I'm not against experimenting with replacing 42 by 32 or by
REDISPLAY_SOME etc., but I don't think we should install anything
along these lines, except if we need to fix a clear bug (i.e. a
redisplay glitch), which this one isn't.

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

> force-mode-line-update should only be needed when changes in the mode
> line are displayed in the middle of running Lisp code.

I think the calls to `force-mode-line-update` in minor mode functions
beg to disagree.  E.g.

    src/emacs -Q --eval '(global-set-key "a" (lambda () (interactive) (setq abbrev-mode (not abbrev-mode))))'

you'll notice that hitting `a` doesn't change the mode line to reflect
the change in `abbrev-mode`.

> We should stop lumping heuristics one on top another, and instead
> redesign this from scratch and make sure that every flag we set is
> acted upon as intended, and only in situations we intend them to be
> acted upon.  E.g., we should be able to set f->redisplay to a value
> that means "update only the frame title".

The `redisplay` bit is not supposed to be a heuristic at all.  It just
tried to keep track more precisely of which part of the redisplay may
have changed.  `fset_redisplay` marks the frame to be redisplayed at the
next redisplay, setting `update_mode_lines` to a non-zero value means
that when redisplaying a window we also redisplay its mode line, so
the suggested hunk definitely doesn't rely on any kind of heuristic.

[ Any chance you got confused thinking that my patch intended to
  stop updating the column/line numbers in frame titles?
  It's most definitely not: the "This said" in my message divides two
  different proposed ways to attack the problem.  ]

The main problems I see with my suggested patch are:
- I don't know if it actually fixes the original problem.
- It can cause *more* redisplay work because it will force redisplay of
  all the windows in the current frame (rather than only their mode
  lines).

> I'm not against experimenting with replacing 42 by 32 or by
> REDISPLAY_SOME etc., but I don't think we should install anything
> along these lines, except if we need to fix a clear bug (i.e. a
> redisplay glitch), which this one isn't.

I don't know what you mean by "along these lines".


        Stefan

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

>> But in the present case, the only change is the w->start
>> an the position of point: these are important enough to need to update
>> the mode line (for the column&line number), but I don't think these are
>> important enough to justify setting `update_mode_lines` to 42:
>> not only other frames can't be affected, but even the current frame's
>> title should basically never be affected either because it would be very
>> unusual to have the line/column number as part of the frame title.
>
> "Unusual" doesn't mean "unsupported".

I just tried to test my proposed patch to see if it breaks this feature,
and it turns out that it's very definitely unusual: I don't know if it's
supposed to be supported, but at least I can say that it doesn't work ;-)

At least:

    emacs -Q --eval '(setq frame-title-format "(%l,%c)")'

shows me "(,)" as the frame title with the code in `master` as well as
with Emacs-25 and Emacs-27.

So maybe the better approach to fix this performance problem is indeed
not with the patch I proposed (which might still be a good idea in
general) but with some other change which refrains from setting
`update_mode_lines` at all just because we're scrolling.


        Stefan

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

> I just tried to test my proposed patch to see if it breaks this feature,
> and it turns out that it's very definitely unusual: I don't know if it's
> supposed to be supported, but at least I can say that it doesn't work ;-)
>
> At least:
>
>     emacs -Q --eval '(setq frame-title-format "(%l,%c)")'
>
> shows me "(,)" as the frame title with the code in `master` as well as
> with Emacs-25 and Emacs-27.

Hmm... so I cooked up the patch below which should solve the original
performance problem, hopefully without introducing any regression, but
while testing it I saw that %p *does* work in frame's titles, so
scrolling can indeed affect the frame-title.

This also means that the patch below should fail sometimes to update the
%p in the frame title, yet I couldn't make it fail :-(

I must be missing something.

I tried

    emacs -Q --eval '(setq frame-title-format "(%l,%c,%p,%I)")' lisp/subr.el

and then scrolling the buffer with `C-v`: frame-title properly updated.
Then I tried to `C-x 5 2` and then `C-M-v` to scroll the window in the
other frame than the selected one: frame-title properly properly updated
as well!

So, now I'm wondering where is the code that causes the frame title to
be (properly) refreshed in my tests!


        Stefan


diff --git a/src/window.c b/src/window.c
index bcc989b5a7..d73289764d 100644
--- a/src/window.c
+++ b/src/window.c
@@ -215,16 +215,25 @@ wset_combination (struct window *w, bool horflag, Lisp_Object val)
     w->horizontal = horflag;
 }
 
+/* Notify that the window's mode line may need to be updated.
+   If AND_FRAME is false, it means that contrary to the window's mode-line,
+   the frame's title can't be affected.  This can be the case because
+   %l and %c don't work in frame titles (i.e. only the window's point
+   has changed).  */
 static void
-wset_update_mode_line (struct window *w)
+wset_update_mode_line (struct window *w, bool and_frame)
 {
   /* If this window is the selected window on its frame, set the
      global variable update_mode_lines, so that gui_consider_frame_title
      will consider this frame's title for redisplay.  */
   Lisp_Object fselected_window = XFRAME (WINDOW_FRAME (w))->selected_window;
 
-  if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
-    update_mode_lines = 42;
+  if (and_frame
+        && WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
+    {
+      update_mode_lines = 2;
+      fset_redisplay (XFRAME (WINDOW_FRAME (w)));
+    }
   else
     w->update_mode_line = true;
 }
@@ -1847,7 +1856,7 @@ DEFUN ("set-window-start", Fset_window_start, Sset_window_start, 2, 3, 0,
   w->start_at_line_beg = false;
   if (NILP (noforce))
     w->force_start = true;
-  wset_update_mode_line (w);
+  wset_update_mode_line (w, false);
   /* Bug#15957.  */
   w->window_end_valid = false;
   wset_redisplay (w);
@@ -4008,7 +4017,7 @@ set_window_buffer (Lisp_Object window, Lisp_Object buffer,
     }
 
   wset_redisplay (w);
-  wset_update_mode_line (w);
+  wset_update_mode_line (w, true);
 
   /* We must select BUFFER to run the window-scroll-functions and to look up
      the buffer-local value of Vwindow_point_insertion_type.  */
@@ -5627,7 +5636,7 @@ window_scroll_pixel_based (Lisp_Object window, int n, bool whole, bool noerror)
 		  set_marker_restricted (w->start, make_fixnum (spos),
 					 w->contents);
 		  w->start_at_line_beg = true;
-		  wset_update_mode_line (w);
+		  wset_update_mode_line (w, false);
 		  /* Set force_start so that redisplay_window will run the
 		     window-scroll-functions.  */
 		  w->force_start = true;
@@ -5812,7 +5821,7 @@ window_scroll_pixel_based (Lisp_Object window, int n, bool whole, bool noerror)
 				  IT_BYTEPOS (it));
       bytepos = marker_byte_position (w->start);
       w->start_at_line_beg = (pos == BEGV || FETCH_BYTE (bytepos - 1) == '\n');
-      wset_update_mode_line (w);
+      wset_update_mode_line (w, false);
       /* Set force_start so that redisplay_window will run the
 	 window-scroll-functions.  */
       w->force_start = true;
@@ -6072,7 +6081,7 @@ window_scroll_line_based (Lisp_Object window, int n, bool whole, bool noerror)
 
       set_marker_restricted_both (w->start, w->contents, pos, pos_byte);
       w->start_at_line_beg = !NILP (bolp);
-      wset_update_mode_line (w);
+      wset_update_mode_line (w, false);
       /* Set force_start so that redisplay_window will run
 	 the window-scroll-functions.  */
       w->force_start = true;

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
> Date: Thu, 17 Dec 2020 14:45:19 -0500
> 
>     src/emacs -Q --eval '(global-set-key "a" (lambda () (interactive) (setq abbrev-mode (not abbrev-mode))))'
> 
> you'll notice that hitting `a` doesn't change the mode line to reflect
> the change in `abbrev-mode`.

That probably just means abbrev-mode should be added to the list at
the end of frame.el.  Or maybe that we need some new mechanism to
trigger update of the lighter on the mode line when a mode is turned
on or off.

And while we are talking about force-mode-line-update: can you explain
why we need to set the prevent_redisplay_optimizations_p flag of the
buffer, in addition to setting update_mode_lines to a magic value?

And btw, redisplaying the mode line in general could mean you need to
redisplay the text area as well, for example when the mode line
changes its height.  So setting update_mode_lines to REDISPLAY_SOME
under the assumption that only the mode line needs to be considered is
not necessarily true and can cause redisplay bugs.

> > We should stop lumping heuristics one on top another, and instead
> > redesign this from scratch and make sure that every flag we set is
> > acted upon as intended, and only in situations we intend them to be
> > acted upon.  E.g., we should be able to set f->redisplay to a value
> > that means "update only the frame title".
> 
> The `redisplay` bit is not supposed to be a heuristic at all.  It just
> tried to keep track more precisely of which part of the redisplay may
> have changed.  `fset_redisplay` marks the frame to be redisplayed at the
> next redisplay, setting `update_mode_lines` to a non-zero value means
> that when redisplaying a window we also redisplay its mode line, so
> the suggested hunk definitely doesn't rely on any kind of heuristic.

Then what is this bit of redisplay_internal about:

  consider_all_windows_p = (update_mode_lines
			    || windows_or_buffers_changed);
  [...]
  if (consider_all_windows_p)
    {
      FOR_EACH_FRAME (tail, frame)
	XFRAME (frame)->updated_p = false;

      propagate_buffer_redisplay ();

      FOR_EACH_FRAME (tail, frame)
	{
   [...]

If the redisplay flag is all we need, how come we must also set
update_mode_lines or windows_or_buffers_changed to get Emacs to
consider anything beyond the selected window?  Why does it have to be
so complicated to say "this frame needs to have all of its windows
reconsidered for redisplay"?

> The main problems I see with my suggested patch are:
> - I don't know if it actually fixes the original problem.

And this is exactly my problem: this is the "heuristic" part I was
talking about.  Instead of knowing exactly which flag does what and
why, we have a combination of flags and global variables, and try
tweaking them until we get the desired result.  This can only work up
to a point, and I think we are well beyond that point.

> - It can cause *more* redisplay work because it will force redisplay of
>   all the windows in the current frame (rather than only their mode
>   lines).

See, we have a single set of conditions that controls when we consider
the frame title, when we consider the mode line, the header-line, the
tab-line, the tool bar, and the menu bar.  It makes very little sense
to me to use the same condition for all of these.

> > I'm not against experimenting with replacing 42 by 32 or by
> > REDISPLAY_SOME etc., but I don't think we should install anything
> > along these lines, except if we need to fix a clear bug (i.e. a
> > redisplay glitch), which this one isn't.
> 
> I don't know what you mean by "along these lines".

"Along these lines" means playing more games with "special" values of
update_mode_lines and windows_or_buffers_changed.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
> Date: Thu, 17 Dec 2020 14:56:40 -0500
> 
> >> But in the present case, the only change is the w->start
> >> an the position of point: these are important enough to need to update
> >> the mode line (for the column&line number), but I don't think these are
> >> important enough to justify setting `update_mode_lines` to 42:
> >> not only other frames can't be affected, but even the current frame's
> >> title should basically never be affected either because it would be very
> >> unusual to have the line/column number as part of the frame title.
> >
> > "Unusual" doesn't mean "unsupported".
> 
> I just tried to test my proposed patch to see if it breaks this feature,
> and it turns out that it's very definitely unusual: I don't know if it's
> supposed to be supported, but at least I can say that it doesn't work ;-)
> 
> At least:
> 
>     emacs -Q --eval '(setq frame-title-format "(%l,%c)")'
> 
> shows me "(,)" as the frame title with the code in `master` as well as
> with Emacs-25 and Emacs-27.

If you meant %l and %c, then we were mis-communicating: these two
aren't supported in frame titles, it's documented.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
> Date: Thu, 17 Dec 2020 15:35:27 -0500
> 
> So, now I'm wondering where is the code that causes the frame title to
> be (properly) refreshed in my tests!

I hope now you better understand why I dislike this kind of messing
with the likes of update_mode_lines and the rest.  We are flying
blind, so how can we hope to arrive at the destination safely and
quickly?

If we want to make any improvements in redisplay efficiency, we should
simply toss what we have and start anew, redefining each flag
accurately and adding more flags/values to augment the existing ones.
Globals like update_mode_lines should simply go away: how long does it
take to loop over all the frames/windows and set the corresponding
flag of each one of them (not that I see why we would even need to do
that for all the windows)?  And the window's update_mode_line flag
should not be used for deciding about all the -lines and frame-title,
we should instead have much more fine-grained flags that would allow
us to make separate decisions regarding each one of them; for example,
when only the column number changes, the flags should tell us that the
mode line might need update, but the frame title definitely doesn't.

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

> That probably just means abbrev-mode should be added to the list at
> the end of frame.el.  Or maybe that we need some new mechanism to
> trigger update of the lighter on the mode line when a mode is turned
> on or off.

Don't know about "new" but the old mechanism is that the standard
minor-mode code ends up calling `force-mode-line-update` (this now
mostly comes from `define-minor-mode`, but in the past it was present in
most "manual" definitions as well).

> And while we are talking about force-mode-line-update: can you explain
> why we need to set the prevent_redisplay_optimizations_p flag of the
> buffer, in addition to setting update_mode_lines to a magic value?

I wish I could, but that bit predates me, and I have no idea what
`prevent_redisplay_optimizations_p` means or does, really.

I just removed it from my local Emacs, to see if I notice any difference.

> And btw, redisplaying the mode line in general could mean you need to
> redisplay the text area as well, for example when the mode line
> changes its height.  So setting update_mode_lines to REDISPLAY_SOME
> under the assumption that only the mode line needs to be considered is
> not necessarily true and can cause redisplay bugs.

I don't see why you relate this problem to REDISPLAY_SOME: when setting
update_mode_lines to other values, xdisp.c should suffer from the same
problem (it presumably updates the mode-lines of all windows without
updating the corresponding window's contents).

>> > We should stop lumping heuristics one on top another, and instead
>> > redesign this from scratch and make sure that every flag we set is
>> > acted upon as intended, and only in situations we intend them to be
>> > acted upon.  E.g., we should be able to set f->redisplay to a value
>> > that means "update only the frame title".
>> 
>> The `redisplay` bit is not supposed to be a heuristic at all.  It just
>> tried to keep track more precisely of which part of the redisplay may
>> have changed.  `fset_redisplay` marks the frame to be redisplayed at the
>> next redisplay, setting `update_mode_lines` to a non-zero value means
>> that when redisplaying a window we also redisplay its mode line, so
>> the suggested hunk definitely doesn't rely on any kind of heuristic.
>
> Then what is this bit of redisplay_internal about:
>
>   consider_all_windows_p = (update_mode_lines
> 			    || windows_or_buffers_changed);
>   [...]
>   if (consider_all_windows_p)
>     {
>       FOR_EACH_FRAME (tail, frame)
> 	XFRAME (frame)->updated_p = false;
>
>       propagate_buffer_redisplay ();
>
>       FOR_EACH_FRAME (tail, frame)
> 	{
>    [...]
>
> If the redisplay flag is all we need, how come we must also set
> update_mode_lines or windows_or_buffers_changed to get Emacs to
> consider anything beyond the selected window?

The `redisplay` bits were designed to reduce the set of windows that we
consider at each redisplay.  Before them, there were the 2 modes you
described in the TODO: either only consider the selected window or
consider all windows.  The `redisplay` bits only come into play when we
get to the "all windows" case.

> Why does it have to be so complicated to say "this frame needs to have
> all of its windows reconsidered for redisplay"?

Is it?  AFAIK `fset_redisplay (f)` is all it takes, which doesn't seem
particularly complex (and neither does its code).

>> The main problems I see with my suggested patch are:
>> - I don't know if it actually fixes the original problem.
> And this is exactly my problem: this is the "heuristic" part I was
> talking about.  Instead of knowing exactly which flag does what and
> why, we have a combination of flags and global variables, and try
> tweaking them until we get the desired result.  This can only work up
> to a point, and I think we are well beyond that point.

Not sure what you're suggesting here.

[ At least I know what the `redisplay` bits are *supposed* to do.
  What I meant by "I don't know if it actually fixes the original
  problem" is that I can't reproduce it locally so I need someone else
  to confirm that it fixes the original problem, and this is not because
  I don't understand what the code I changed does, but because I don't
  know enough about the problem to be sure that my fix addresses the
  actual problem.  ]

>> - It can cause *more* redisplay work because it will force redisplay of
>>   all the windows in the current frame (rather than only their mode
>>   lines).
>
> See, we have a single set of conditions that controls when we consider
> the frame title, when we consider the mode line, the header-line, the
> tab-line, the tool bar, and the menu bar.  It makes very little sense
> to me to use the same condition for all of these.

I think it makes a lot of sense from the point of view of managing
code complexity.  But indeed, it leaves open optimization opportunities,
so we could refine the info used to keep track of what needs to
be redisplayed.

>> > I'm not against experimenting with replacing 42 by 32 or by
>> > REDISPLAY_SOME etc., but I don't think we should install anything
>> > along these lines, except if we need to fix a clear bug (i.e. a
>> > redisplay glitch), which this one isn't.
>> I don't know what you mean by "along these lines".
> "Along these lines" means playing more games with "special" values of
> update_mode_lines and windows_or_buffers_changed.

I don't know what you mean by "special values".
And I'm not playing any games here.

The meaning of those vars is as follows:

- update_mode_lines == 0 means that none of the mode lines (and
  relatives) needs to be updated.
- update_mode_lines > 2 means that all the mode lines in all windows
  need to be updated.
- update_mode_lines == 2 means that all the mode lines need to be
  updated in the set designated by the `redisplay` bits (where the
  `redisplay` on a frame means that all of its windows are also part opf
  the set, and where the `redisplay` bit of a buffer means that all the
  windows that display this buffer are also part of the set).

- windows_or_buffers_changed == 0 means that only the selected window's
  content may need to be updated.
- update_mode_lines > 2 means that the contents in all windows
  may need to be updated.
- update_mode_lines == 2 means that the contents in all windows in the
  set designated by the `redisplay` bits may need to be updated.


        Stefan

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

> If we want to make any improvements in redisplay efficiency, we should
> simply toss what we have and start anew, redefining each flag
> accurately and adding more flags/values to augment the existing ones.

AFAIK that's exactly what I did with the `redisplay` bits.

> Globals like update_mode_lines should simply go away: how long does it
> take to loop over all the frames/windows and set the corresponding
> flag of each one of them (not that I see why we would even need to do
> that for all the windows)?

And indeed, my `redisplay` bits intend to replace that
global variable, tho I've kept it for now in order to make the change
more conservative: while looping over all the windows/frames may be fast
if you do it once per command, it's quite possible to run code that sets
`update_mode_lines` many times in a single command, and if you have
a hundred frames/windows like I often do, this could end up making the
code measurably slower in some corner cases.  I doubt I'd be bothered,
but I didn't want to take the risk of introducing such
performance regressions.

Similarly, I kept the special case where we only consider the selected
window.  We could get rid of it and only rely on the `redisplay` bits
instead, but it could make things marginally slower in some cases, and
it would have a required more work to try and better understand what
that "selected window only" code path does to make sure I wasn't
introducing any regression.

> And the window's update_mode_line flag should not be used for deciding
> about all the -lines and frame-title, we should instead have much more
> fine-grained flags that would allow us to make separate decisions
> regarding each one of them;

That would be nice, yes.  But that's largely independent from the bug
under discussion, where the performance seems to be adequate with the
current coarse grained flags as long as we have a single frame, so the
problem seems to be that we consider all frames instead of only
considering those displaying the affected windows.


        Stefan

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >     if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
 > -    update_mode_lines = 42;
 > +    {
 > +      update_mode_lines = 2;
 > +      fset_redisplay (XFRAME (WINDOW_FRAME (w)));
 > +    }
 >     else
 >       w->update_mode_line = true;

Why penalize people with >= 2 windows per selected frame when scrolling
one of them by updating all the others' mode, header, tab lines?

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> In the case at hand Emacs relies on redisplaying all frames when
 >> scrolling a window that is not on the selected frame in order to
 >> correctly reflect the change in the scrolled window's mode line.
 >
 > That's not my understanding.  My understanding is that the user
 > scrolls the _selected_ window, because otherwise wset_update_mode_line
 > doesn't set update_mode_lines:
 >
 >    static void
 >    wset_update_mode_line (struct window *w)
 >    {
 >      /* If this window is the selected window on its frame, set the
 >         global variable update_mode_lines, so that gui_consider_frame_title
 >         will consider this frame's title for redisplay.  */
 >      Lisp_Object fselected_window = XFRAME (WINDOW_FRAME (w))->selected_window;
 >
 >      if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
 >        update_mode_lines = 42;
 >      else
 >        w->update_mode_line = true;
 >    }

Indeed, you're right.  This doesn't make any sense to me at all.  Why
should a non-selected frame care about whether I scrolled a window on
the selected frame?

 >> IIUC windows_or_buffers_changed affects frames as well.  For example, I
 >> have no idea why making a frame (in)visible should redisplay all other
 >> frames while moving a frame on the screen apparently does not.
 >
 > That's commented out now,

Not in Fmake_frame_invisible AFAICT.

 > although the comment seems to hint on the
 > reason.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

> Why penalize people with >= 2 windows per selected frame when scrolling
> one of them by updating all the others' mode, header, tab lines?

Because nobody implemented the code to optimize that extra work away.
BTW, the patch below is what I use in my own branch now.


        Stefan


diff --git a/src/window.c b/src/window.c
index 20b0ef1525..c4f89b934e 100644
--- a/src/window.c
+++ b/src/window.c
@@ -224,7 +224,12 @@ wset_update_mode_line (struct window *w)
   Lisp_Object fselected_window = XFRAME (WINDOW_FRAME (w))->selected_window;
 
   if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
-    update_mode_lines = 42;
+    {
+      /* FIXME: This should be in xdisp.c, next to fset_redisplay
+         and friends!  */
+      update_mode_lines = 2;    /* FIXME: REDISPLAY_SOME  */
+      XFRAME (WINDOW_FRAME (w))->redisplay = true;
+    }
   else
     w->update_mode_line = true;
 }

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

>>     if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
>> -    update_mode_lines = 42;
>> +    {
>> +      update_mode_lines = 2;
>> +      XFRAME (WINDOW_FRAME (w))->redisplay = true;
>> +    }
>>     else
>>       w->update_mode_line = true;
>
> Why penalize people with >= 2 windows per selected frame when scrolling
> one of them by updating all the others' mode, header, tab lines?

BTW, I don't quite understand this question, tho: my patch definitely
doesn't make things work any worse than they do now: currently, all
the mode-lines (and relatives) are updated on all windows on all frames.
My patch reduces this so it's only done on the selected frame (but still
all windows of that one frame, indeed :-(  ).


        Stefan

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
> Date: Thu, 17 Dec 2020 16:07:19 -0500
> 
> > That probably just means abbrev-mode should be added to the list at
> > the end of frame.el.  Or maybe that we need some new mechanism to
> > trigger update of the lighter on the mode line when a mode is turned
> > on or off.
> 
> Don't know about "new" but the old mechanism is that the standard
> minor-mode code ends up calling `force-mode-line-update` (this now
> mostly comes from `define-minor-mode`, but in the past it was present in
> most "manual" definitions as well).

IMO, that shouldn't be needed.  And force-mode-line-update has its own
problems, see the many questions about why it doesn't do what the
caller thought it would.

> > And while we are talking about force-mode-line-update: can you explain
> > why we need to set the prevent_redisplay_optimizations_p flag of the
> > buffer, in addition to setting update_mode_lines to a magic value?
> 
> I wish I could, but that bit predates me, and I have no idea what
> `prevent_redisplay_optimizations_p` means or does, really.
> 
> I just removed it from my local Emacs, to see if I notice any difference.

My point is that we are dealing with a bunch of global and local flags
with overlapping functionality about which we have no clear idea what
each one is doing.  Removing a flag will not solve that basic problem,
because I don't doubt that some of these flags is needed in some,
perhaps subtle and rare, situation.  We won't find flags that could be
removed without unwanted consequences.

> > And btw, redisplaying the mode line in general could mean you need to
> > redisplay the text area as well, for example when the mode line
> > changes its height.  So setting update_mode_lines to REDISPLAY_SOME
> > under the assumption that only the mode line needs to be considered is
> > not necessarily true and can cause redisplay bugs.
> 
> I don't see why you relate this problem to REDISPLAY_SOME: when setting
> update_mode_lines to other values, xdisp.c should suffer from the same
> problem (it presumably updates the mode-lines of all windows without
> updating the corresponding window's contents).

My point is that the documentation says REDISPLAY_SOME causes only the
mode line(s) to be updated, but the idea that changes which affect the
mode line could be handled by using REDISPLAY_SOME is incorrect
because it assumes the windows above and below will never be affected
by such changes.  So the idea itself is flawed, albeit in very rare
and somewhat unusual use cases.

I hoped that this will lead to the conclusion that the current
partition of possible use cases and its translation into specific sets
of values of the flags and variables we have is at least inaccurate
and incomplete, if not worse.  With the implied realization that we
need to rethink this and then reimplement it.

> >   consider_all_windows_p = (update_mode_lines
> > 			    || windows_or_buffers_changed);
> >   [...]
> >   if (consider_all_windows_p)
> >     {
> >       FOR_EACH_FRAME (tail, frame)
> > 	XFRAME (frame)->updated_p = false;
> >
> >       propagate_buffer_redisplay ();
> >
> >       FOR_EACH_FRAME (tail, frame)
> > 	{
> >    [...]
> >
> > If the redisplay flag is all we need, how come we must also set
> > update_mode_lines or windows_or_buffers_changed to get Emacs to
> > consider anything beyond the selected window?
> 
> The `redisplay` bits were designed to reduce the set of windows that we
> consider at each redisplay.

Then why do we need the consider_all_windows_p condition, which is
based on 2 other variables?  It should have been enough to simply go
over all the redisplay flags of all the frames and windows and
buffers, and see if any of them are set for any window other than the
selected window of the selected frame.  Right?

> > Why does it have to be so complicated to say "this frame needs to have
> > all of its windows reconsidered for redisplay"?
> 
> Is it?  AFAIK `fset_redisplay (f)` is all it takes, which doesn't seem
> particularly complex (and neither does its code).

So you are saying that wset_update_mode_line should only set the
frame's redisplay flag?  If so, why didn't your patch to do just that
work?

> >> The main problems I see with my suggested patch are:
> >> - I don't know if it actually fixes the original problem.
> > And this is exactly my problem: this is the "heuristic" part I was
> > talking about.  Instead of knowing exactly which flag does what and
> > why, we have a combination of flags and global variables, and try
> > tweaking them until we get the desired result.  This can only work up
> > to a point, and I think we are well beyond that point.
> 
> Not sure what you're suggesting here.

I suggest that we should have a system for selectively redisplaying
parts of the Emacs display where we do know which change will fix what
problem.  IOW, we should rethink all of this, remove the flags that
shouldn't be needed, maybe add flags that are missing, and augment/fix
the existing ones which do make sense (that definitely includes the
various redisplay flags we have now, but they are not enough and
perhaps should not be simple booleans).

> [ At least I know what the `redisplay` bits are *supposed* to do.

Yes, I also think I know what each of those variables is _supposed_ to
do.  The problem is, they don't quite do what I think they should, not
always anyway.

> > See, we have a single set of conditions that controls when we consider
> > the frame title, when we consider the mode line, the header-line, the
> > tab-line, the tool bar, and the menu bar.  It makes very little sense
> > to me to use the same condition for all of these.
> 
> I think it makes a lot of sense from the point of view of managing
> code complexity.  But indeed, it leaves open optimization opportunities,
> so we could refine the info used to keep track of what needs to
> be redisplayed.

And that's because the flags we use, however numerous, are too blunt
for selectively specifying which parts to redisplay.  Which AFAIU is
the crux of this bug report.

> >> > I'm not against experimenting with replacing 42 by 32 or by
> >> > REDISPLAY_SOME etc., but I don't think we should install anything
> >> > along these lines, except if we need to fix a clear bug (i.e. a
> >> > redisplay glitch), which this one isn't.
> >> I don't know what you mean by "along these lines".
> > "Along these lines" means playing more games with "special" values of
> > update_mode_lines and windows_or_buffers_changed.
> 
> I don't know what you mean by "special values".
> And I'm not playing any games here.

This is not useful: you are responding to the specific words I used
instead of responding to what I meant (which I think is fairly
obvious).

> The meaning of those vars is as follows:
> 
> - update_mode_lines == 0 means that none of the mode lines (and
>   relatives) needs to be updated.
> - update_mode_lines > 2 means that all the mode lines in all windows
>   need to be updated.
> - update_mode_lines == 2 means that all the mode lines need to be
>   updated in the set designated by the `redisplay` bits (where the
>   `redisplay` on a frame means that all of its windows are also part opf
>   the set, and where the `redisplay` bit of a buffer means that all the
>   windows that display this buffer are also part of the set).
> 
> - windows_or_buffers_changed == 0 means that only the selected window's
>   content may need to be updated.

Yes, I know.  The comments you provided tell this much.  The problem
is, the reality is subtly and annoyingly different, and that is not
good for maintainability.

> - update_mode_lines > 2 means that the contents in all windows
>   may need to be updated.
> - update_mode_lines == 2 means that the contents in all windows in the
>   set designated by the `redisplay` bits may need to be updated.

Copy/paste? did you mean windows_or_buffers_changed?

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
> Date: Thu, 17 Dec 2020 16:24:01 -0500
> 
> > And the window's update_mode_line flag should not be used for deciding
> > about all the -lines and frame-title, we should instead have much more
> > fine-grained flags that would allow us to make separate decisions
> > regarding each one of them;
> 
> That would be nice, yes.  But that's largely independent from the bug
> under discussion, where the performance seems to be adequate with the
> current coarse grained flags as long as we have a single frame, so the
> problem seems to be that we consider all frames instead of only
> considering those displaying the affected windows.

No, the problem is that we turn on update_mode_lines because we need
to make sure the title of the _selected_ frame, a single frame, is
updated due to possible effects of scrolling on that single title.
And the effect is to consider the titles (and menu bars and tool bars)
on all frames instead, which is definitely unnecessary.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 18 Dec 2020 00:19:48 +0100
> 
>  > That's not my understanding.  My understanding is that the user
>  > scrolls the _selected_ window, because otherwise wset_update_mode_line
>  > doesn't set update_mode_lines:
>  >
>  >    static void
>  >    wset_update_mode_line (struct window *w)
>  >    {
>  >      /* If this window is the selected window on its frame, set the
>  >         global variable update_mode_lines, so that gui_consider_frame_title
>  >         will consider this frame's title for redisplay.  */
>  >      Lisp_Object fselected_window = XFRAME (WINDOW_FRAME (w))->selected_window;
>  >
>  >      if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
>  >        update_mode_lines = 42;
>  >      else
>  >        w->update_mode_line = true;
>  >    }
> 
> Indeed, you're right.  This doesn't make any sense to me at all.  Why
> should a non-selected frame care about whether I scrolled a window on
> the selected frame?

The non-selected frames shouldn't.  But the selected frame should,
because it needs to re-evaluate its frame title.  And we don't have
any means to tell the display engine to consider only the frame title
on a single frame.  We only have the means to tell it which windows on
which frames may need redrawing, but the frame's title doesn't belong
to any window.

>  >> IIUC windows_or_buffers_changed affects frames as well.  For example, I
>  >> have no idea why making a frame (in)visible should redisplay all other
>  >> frames while moving a frame on the screen apparently does not.
>  >
>  > That's commented out now,
> 
> Not in Fmake_frame_invisible AFAICT.
> 
>  > although the comment seems to hint on the
>  > reason.

What about that comment? doesn't it explain the reason?  AFAIU, that
reason is the need to re-evaluate the menu bar.

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> Why penalize people with >= 2 windows per selected frame when scrolling
 >> one of them by updating all the others' mode, header, tab lines?
 >
 > BTW, I don't quite understand this question, tho: my patch definitely
 > doesn't make things work any worse than they do now: currently, all
 > the mode-lines (and relatives) are updated on all windows on all frames.
 > My patch reduces this so it's only done on the selected frame (but still
 > all windows of that one frame, indeed :-(  ).

Indeed I asked that before I realized (see my last mail to Eli) that the
old code did it the other way round and thus completely wrong IMO.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> Indeed, you're right.  This doesn't make any sense to me at all.  Why
 >> should a non-selected frame care about whether I scrolled a window on
 >> the selected frame?
 >
 > The non-selected frames shouldn't.  But the selected frame should,
 > because it needs to re-evaluate its frame title.  And we don't have
 > any means to tell the display engine to consider only the frame title
 > on a single frame.  We only have the means to tell it which windows on
 > which frames may need redrawing, but the frame's title doesn't belong
 > to any window.

In redisplay_window we set

   update_mode_line = (w->update_mode_line
		      || update_mode_lines

where w is the window we redisplay because it got scrolled.  Later down
we have

   if (update_mode_line
       && EQ (FRAME_SELECTED_WINDOW (f), window))
     {
       ...
       gui_consider_frame_title (w->frame);

so we do update the frame title after the frame's selected window got
scrolled.  What am I missing?

 >> Not in Fmake_frame_invisible AFAICT.
 >>
 >>   > although the comment seems to hint on the
 >>   > reason.
 >
 > What about that comment? doesn't it explain the reason?  AFAIU, that
 > reason is the need to re-evaluate the menu bar.

Because we just made a frame invisible?  The only thing we could grey
out on a menu in such a case is C-x 5 o and that's not what I see.  And
if it were there, we'd have to handle it in Fmake_frame_visible as well.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 18 Dec 2020 09:39:35 +0100
> 
>  > The non-selected frames shouldn't.  But the selected frame should,
>  > because it needs to re-evaluate its frame title.  And we don't have
>  > any means to tell the display engine to consider only the frame title
>  > on a single frame.  We only have the means to tell it which windows on
>  > which frames may need redrawing, but the frame's title doesn't belong
>  > to any window.
> 
> In redisplay_window we set
> 
>    update_mode_line = (w->update_mode_line
> 		      || update_mode_lines
> 
> where w is the window we redisplay because it got scrolled.  Later down
> we have
> 
>    if (update_mode_line
>        && EQ (FRAME_SELECTED_WINDOW (f), window))
>      {
>        ...
>        gui_consider_frame_title (w->frame);
> 
> so we do update the frame title after the frame's selected window got
> scrolled.  What am I missing?

This, I think:

  if (current_matrix_up_to_date_p
      && (rc = try_cursor_movement (window, startp, &temp_scroll_step),
	  rc != CURSOR_MOVEMENT_CANNOT_BE_USED))
    {
      switch (rc)
	{
	case CURSOR_MOVEMENT_SUCCESS:
	  used_current_matrix_p = true;
	  goto done;

IOW, we might think that nothing needs to be updated except perhaps
the cursor position, and then fail to update the frame's title.

And maybe there are more loopholes like this one, I didn't try to scan
the code too thoroughly.

>  >> Not in Fmake_frame_invisible AFAICT.
>  >>
>  >>   > although the comment seems to hint on the
>  >>   > reason.
>  >
>  > What about that comment? doesn't it explain the reason?  AFAIU, that
>  > reason is the need to re-evaluate the menu bar.
> 
> Because we just made a frame invisible?  The only thing we could grey
> out on a menu in such a case is C-x 5 o and that's not what I see.  And
> if it were there, we'd have to handle it in Fmake_frame_visible as well.

This code is old (1994), maybe it tries to handle a problem that no
longer exist?  Who knows how the Buffers menu looked back then?

bug#42406: Mouse-wheel scrolling can be flickering

[martin rudalics]

 >> In redisplay_window we set
 >>
 >>     update_mode_line = (w->update_mode_line
 >> 		      || update_mode_lines
 >>
 >> where w is the window we redisplay because it got scrolled.  Later down
 >> we have
 >>
 >>     if (update_mode_line
 >>         && EQ (FRAME_SELECTED_WINDOW (f), window))
 >>       {
 >>         ...
 >>         gui_consider_frame_title (w->frame);
 >>
 >> so we do update the frame title after the frame's selected window got
 >> scrolled.  What am I missing?
 >
 > This, I think:
 >
 >    if (current_matrix_up_to_date_p
 >        && (rc = try_cursor_movement (window, startp, &temp_scroll_step),
 > 	  rc != CURSOR_MOVEMENT_CANNOT_BE_USED))
 >      {
 >        switch (rc)
 > 	{
 > 	case CURSOR_MOVEMENT_SUCCESS:
 > 	  used_current_matrix_p = true;
 > 	  goto done;
 >
 > IOW, we might think that nothing needs to be updated except perhaps
 > the cursor position, and then fail to update the frame's title.

Just to make sure I understand your argument correctly: With my xdisp.c

   update_mode_line = (w->update_mode_line is on line 18065

   case CURSOR_MOVEMENT_SUCCESS: is on line 18458

   done: is on line 18929

   if (update_mode_line is on line 18975

   gui_consider_frame_title (w->frame); is on line 19020

so I can't see why a CURSOR_MOVEMENT_SUCCESS could bypass
gui_consider_frame_title.

martin

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

>> That would be nice, yes.  But that's largely independent from the bug
>> under discussion, where the performance seems to be adequate with the
>> current coarse grained flags as long as we have a single frame, so the
>> problem seems to be that we consider all frames instead of only
>> considering those displaying the affected windows.
>
> No, the problem is that we turn on update_mode_lines because we need
> to make sure the title of the _selected_ frame, a single frame, is
> updated due to possible effects of scrolling on that single title.
> And the effect is to consider the titles (and menu bars and tool bars)
> on all frames instead, which is definitely unnecessary.

I fail to see the difference between what you're saying and what I'm saying.


        Stefan

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

>> > That probably just means abbrev-mode should be added to the list at
>> > the end of frame.el.  Or maybe that we need some new mechanism to
>> > trigger update of the lighter on the mode line when a mode is turned
>> > on or off.
>> Don't know about "new" but the old mechanism is that the standard
>> minor-mode code ends up calling `force-mode-line-update` (this now
>> mostly comes from `define-minor-mode`, but in the past it was present in
>> most "manual" definitions as well).
> IMO, that shouldn't be needed.

But it is, currently.

> My point is that we are dealing with a bunch of global and local flags
> with overlapping functionality about which we have no clear idea what
> each one is doing.  Removing a flag will not solve that basic problem,
> because I don't doubt that some of these flags is needed in some,
> perhaps subtle and rare, situation.  We won't find flags that could be
> removed without unwanted consequences.

IME a good to way to find out what a chunk of code is for is to remove
it and see what happens.  It's not the only way and not always the best
way either, of course.

> My point is that the documentation says REDISPLAY_SOME causes only the
> mode line(s) to be updated, but the idea that changes which affect the
> mode line could be handled by using REDISPLAY_SOME is incorrect
> because it assumes the windows above and below will never be affected
> by such changes.  So the idea itself is flawed, albeit in very rare
> and somewhat unusual use cases.

I can see how a mode-line update can reduce the height of the
mode-line and this require to display "more" of the contents of the
attached window.  But:
- I don't know how/where this is currently handled in the redisplay
  (I do have some ideas of how it *could* be handled, OTOH ;-)
- I don't see how this can also require display updates in the window
  that's below.
- more importantly, I don't see how this relates to REDISPLAY_SOME: it
  seems to be an issue of "update mode lines may require updates in
  window contents" and that issue is linked to the division between
  `update_mode_lines` and `windows_or_buffers_changed` but that is
  orthogonal to the REDISPLAY_SOME one.

> I hoped that this will lead to the conclusion that the current
> partition of possible use cases and its translation into specific sets
> of values of the flags and variables we have is at least inaccurate
> and incomplete, if not worse.  With the implied realization that we
> need to rethink this and then reimplement it.

In case you're curious, here's my idea of how I think the above problem
could be attacked.

    bool redisplay_bits_set;

    fset_redisplay ()
    { ...; redisplay_bits_set = true; }
    [...]

    redisplay ()
    {
       if (redisplay_bits_set)
         redisplay_internal ();
       if (redisplay_bits_set)
         /* Redisplay itself caused further changes.  So try again.
            This second redisplay could potentially cause yet more changes,
            but it *really* should not.
            If it does, then tough luck: we won't take the risk of
            inf-looping for it so the result will only be seen at the
            next redisplay.  */
         redisplay_internal ();
    }

>> >   consider_all_windows_p = (update_mode_lines
>> > 			    || windows_or_buffers_changed);
>> >   [...]
>> >   if (consider_all_windows_p)
>> >     {
>> >       FOR_EACH_FRAME (tail, frame)
>> > 	XFRAME (frame)->updated_p = false;
>> >
>> >       propagate_buffer_redisplay ();
>> >
>> >       FOR_EACH_FRAME (tail, frame)
>> > 	{
>> >    [...]
>> >
>> > If the redisplay flag is all we need, how come we must also set
>> > update_mode_lines or windows_or_buffers_changed to get Emacs to
>> > consider anything beyond the selected window?
>> The `redisplay` bits were designed to reduce the set of windows that we
>> consider at each redisplay.
> Then why do we need the consider_all_windows_p condition, which is
> based on 2 other variables?

That's because I kept the special case where redisplay only considers
the selected window as explained earlier.

> It should have been enough to simply go over all the redisplay flags
> of all the frames and windows and buffers, and see if any of them are
> set for any window other than the selected window of the selected
> frame.  Right?

Yes.  I explained yesterday why I didn't do that back then:

    Similarly, I kept the special case where we only consider the selected
    window.  We could get rid of it and only rely on the `redisplay` bits
    instead, but it could make things marginally slower in some cases, and
    it would have a required more work to try and better understand what
    that "selected window only" code path does to make sure I wasn't
    introducing any regression.

But if someone wants to go ahead and do that, I'd welcome it.

>> > Why does it have to be so complicated to say "this frame needs to have
>> > all of its windows reconsidered for redisplay"?
>> Is it?  AFAIK `fset_redisplay (f)` is all it takes, which doesn't seem
>> particularly complex (and neither does its code).
> So you are saying that wset_update_mode_line should only set the
> frame's redisplay flag?  If so, why didn't your patch to do just that
> work?

AFAIK that is what my patch does.

> And that's because the flags we use, however numerous, are too blunt
> for selectively specifying which parts to redisplay.  Which AFAIU is
> the crux of this bug report.

Since the performance is good enough in the single-frame case (even
though it does perform a lot of unnecessary work), I think the
`redisplay` bits are sufficient for the needs of this bug-report (since
they are perfectly sufficient to reduce the many-frames case down to the
single-frame case).

>> >> > I'm not against experimenting with replacing 42 by 32 or by
>> >> > REDISPLAY_SOME etc., but I don't think we should install anything
>> >> > along these lines, except if we need to fix a clear bug (i.e. a
>> >> > redisplay glitch), which this one isn't.
>> >> I don't know what you mean by "along these lines".
>> > "Along these lines" means playing more games with "special" values of
>> > update_mode_lines and windows_or_buffers_changed.
>> I don't know what you mean by "special values".
>> And I'm not playing any games here.
> This is not useful: you are responding to the specific words I used
> instead of responding to what I meant (which I think is fairly
> obvious).

I'm afraid it's not obvious enough for me.  I'm not playing with words,
I was only quoting the specific words which I think are the source of my
lack of understanding of what you meant.

>> The meaning of those vars is as follows:
>>
>> - update_mode_lines == 0 means that none of the mode lines (and
>>   relatives) needs to be updated.
>> - update_mode_lines > 2 means that all the mode lines in all windows
>>   need to be updated.
>> - update_mode_lines == 2 means that all the mode lines need to be
>>   updated in the set designated by the `redisplay` bits (where the
>>   `redisplay` on a frame means that all of its windows are also part opf
>>   the set, and where the `redisplay` bit of a buffer means that all the
>>   windows that display this buffer are also part of the set).
>>
>> - windows_or_buffers_changed == 0 means that only the selected window's
>>   content may need to be updated.
>
> Yes, I know.  The comments you provided tell this much.  The problem
> is, the reality is subtly and annoyingly different, and that is not
> good for maintainability.

When it's different, please consider it as a bug rather than as "the doc
doesn't match reality".  For that reason I believe the patch below is
*right*.

Maybe it'll introduce regressions, in which case it should indicate that
we have a bug elsewhere, and maybe it won't improve the original problem
(e.g. because 42 is only one of the causes why the redisplay has to
reconsider all the windows/frames), but it is a step in the right direction.

To be clear: I have no intention to push this to `emacs-27`, but
I can't see any good reason not to push it to master (after fixing its
FIXME, obviously).

>> - update_mode_lines > 2 means that the contents in all windows
>>   may need to be updated.
>> - update_mode_lines == 2 means that the contents in all windows in the
>>   set designated by the `redisplay` bits may need to be updated.
>
> Copy/paste? did you mean windows_or_buffers_changed?

Indeed, sorry.


        Stefan


diff --git a/src/window.c b/src/window.c
index bcc989b5a7..9b88c18142 100644
--- a/src/window.c
+++ b/src/window.c
@@ -224,7 +224,13 @@ wset_update_mode_line (struct window *w)
   Lisp_Object fselected_window = XFRAME (WINDOW_FRAME (w))->selected_window;
 
   if (WINDOWP (fselected_window) && XWINDOW (fselected_window) == w)
-    update_mode_lines = 42;
+    {
+      /* FIXME: This should be in xdisp.c, next to fset_redisplay
+         and friends!  */
+      if (!update_mode_lines)
+        update_mode_lines = 2;    /* FIXME: REDISPLAY_SOME  */
+      XFRAME (WINDOW_FRAME (w))->redisplay = true;
+    }
   else
     w->update_mode_line = true;
 }

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
> Date: Fri, 18 Dec 2020 11:22:40 -0500
> 
> To be clear: I have no intention to push this to `emacs-27`, but
> I can't see any good reason not to push it to master (after fixing its
> FIXME, obviously).

I thought I already explained why I'm not interested in such "fixes".
I'd welcome a thorough redesign of the flags and introduction of new
flags to allow us to redraw specific parts like frame titles and menu
bars (or new values of existing flags to the same effect).  Then it
will be worth our while to risk breaking some use cases.  But I don't
want to increase the existing mess by lumping more and more logic on
top of what we already have, because that brings the same risks
without any benefits.  Sorry.

Oh, and your question about where the change in mode-line dimensions
is handled? it's here:

      display_mode_lines (w);

      /* If mode line height has changed, arrange for a thorough
	 immediate redisplay using the correct mode line height.  */
      if (window_wants_mode_line (w)
	  && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
	{
	  f->fonts_changed = true;
	  w->mode_line_height = -1;
	  MATRIX_MODE_LINE_ROW (w->current_matrix)->height
	    = DESIRED_MODE_LINE_HEIGHT (w);
	}
      [...]
      if (f->fonts_changed)
	goto need_larger_matrices;

bug#42406: Mouse-wheel scrolling can be flickering

[Stefan Monnier]

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
>> Date: Fri, 18 Dec 2020 11:22:40 -0500
>> 
>> To be clear: I have no intention to push this to `emacs-27`, but
>> I can't see any good reason not to push it to master (after fixing its
>> FIXME, obviously).
>
> I thought I already explained why I'm not interested in such "fixes".

I resent the way you used scare-quotes around this word.
This *is* a fix and it only touches "flags" whose semantics we
understand well.

Any change to the redisplay will risk introducing regressions because of
the previous code's intricate workings so if you reject this simple
change, I can't see why you wouldn't reject similarly any other change
to the redisplay (including your advocated big redesign).

After all, my `redisplay` bits did pretty much exactly what you suggest
we do, except that they did not try to use a finer distinction between
frametitles, headerlines, modelines, ...

I really just don't understand your stance here.

> Oh, and your question about where the change in mode-line dimensions
> is handled? it's here:
>
>       display_mode_lines (w);
>
>       /* If mode line height has changed, arrange for a thorough
> 	 immediate redisplay using the correct mode line height.  */
>       if (window_wants_mode_line (w)
> 	  && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
> 	{
> 	  f->fonts_changed = true;
> 	  w->mode_line_height = -1;
> 	  MATRIX_MODE_LINE_ROW (w->current_matrix)->height
> 	    = DESIRED_MODE_LINE_HEIGHT (w);
> 	}
>       [...]
>       if (f->fonts_changed)
> 	goto need_larger_matrices;

Ah, right, thanks, that makes sense.  And it shows that the division
between "mode-lines" and "window contents" was a good idea, since in
most cases they can be handled separately and in the few cases where
they can't, we can easily arrange to augment the amount that's actually
redisplayed once we discover that more needs to be done.


        Stefan

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
> Date: Fri, 18 Dec 2020 18:12:45 -0500
> 
> Any change to the redisplay will risk introducing regressions because of
> the previous code's intricate workings so if you reject this simple
> change, I can't see why you wouldn't reject similarly any other change
> to the redisplay (including your advocated big redesign).
> 
> After all, my `redisplay` bits did pretty much exactly what you suggest
> we do, except that they did not try to use a finer distinction between
> frametitles, headerlines, modelines, ...
> 
> I really just don't understand your stance here.

My stance is that the problem is minor (I cannot even see it on my
system, so it could well be specific to NS), and thus the change is
unjustified because its benefits are basically nil.

If that same change would motivate a redesign I described, we'd
benefit much more from that, so it would be justified to sustain even
greater risks.

bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, alan@idiocy.org, 42406@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 18 Dec 2020 14:57:01 +0100
> 
>  > 	case CURSOR_MOVEMENT_SUCCESS:
>  > 	  used_current_matrix_p = true;
>  > 	  goto done;
>  >
>  > IOW, we might think that nothing needs to be updated except perhaps
>  > the cursor position, and then fail to update the frame's title.
> 
> Just to make sure I understand your argument correctly: With my xdisp.c
> 
>    update_mode_line = (w->update_mode_line is on line 18065
> 
>    case CURSOR_MOVEMENT_SUCCESS: is on line 18458
> 
>    done: is on line 18929
> 
>    if (update_mode_line is on line 18975
> 
>    gui_consider_frame_title (w->frame); is on line 19020
> 
> so I can't see why a CURSOR_MOVEMENT_SUCCESS could bypass
> gui_consider_frame_title.

Right you are.  So I guess I don't have an answer for your question,m
and more digging needs to be done to figure out if we really need what
scrolling commands do.

bug#42406: macOS metal rendering engine in mac port

[Konrad Podczeck]

Aaron,

could you please also look on the performance of wheel-mouse scrolling in all the scenarios below, to see whether it makes a difference:

laptop screen and NS port

big screen and NS port

laptop screen and Macport with metal rendering

big screen and Macport with metal rendering

laptop screen and Macport without metal rendering
 
big screen and Macport without metal rendering

(Drag an Emacs frame to full size of the monitor with a big screen.)

Konrad

bug#42406: macOS metal rendering engine in mac port

[Aaron Jensen]

On Fri, May 21, 2021 at 3:23 AM Konrad Podczeck
<konrad.podczeck@univie.ac.at> wrote:
>
> Aaron,
>
> could you please also look on the performance of wheel-mouse scrolling in all the scenarios below, to see whether it makes a difference:

I can't really feel much of a difference with wheel mouse scrolling.
Trackpad scrolling has a significant difference however, with NS port
being the winner regardless of frame size. Metal feels slightly more
sluggish than non-metal macport.

Disabling mac-mouse-wheel-smooth-scroll on macport helps immensely and
I'd say macport without metal feels slightly better than NS when that
is disabled metal feels similar or slightly worse to NS.

And in all cases a smaller screen makes it feel more smooth, but the
stack ranking remains the same.

Not super scientific, but hopefully helpful.