Scrolling sensitivity in macOS with retina display

[michaelkix]

(I'm not sure this has anything to do with retina display.)

Scrolling speed/sensitivity seems low compared to other terminals - about half the expected one.

I use a locally modified version of kitty with this change in scroll_event() in mouse.c even though I'm not sure this is the correct way to do it:

-        double pixels = global_state.callback_os_window->pending_scroll_pixels + yoffset;
+        double pixels = global_state.callback_os_window->pending_scroll_pixels + yoffset * global_state.callback_os_window->viewport_y_ratio;

On my machine viewport_y_ratio is 2.0.

Unrelated: thanks for kitty - I like it very much and use it on a daily basis. Other terminals are way too slow for my liking.

[Luflosi]

I think it has everything to do with the retina display. I don't have a retina display and for me viewport_y_ratio is 1.0. You can make a pull request if you want but if you do, put global_state.callback_os_window->pending_scroll_pixels + yoffset in parenthesis
so that global_state.callback_os_window->pending_scroll_pixels is also multiplied by the factor.

[michaelkix]

Wouldn't this lead to pending_scroll_pixels being multiplied by 2 twice?
The result of the computation is accumulated into pending_scroll_pixels if I understand correctly, everything these is already pre-multiplied.

[Luflosi]

Yeah, you're right, my bad. I thought about it a bit more and I think the best thing to do is to multiply yoffset by viewport_y_ratio before it's used for the first time. @kovidgoyal should yoffset be multiplied by viewport_y_ratio even when is_high_resolution is false? @michaelkix depending on the answer the best place to put this multiplication is probably either before or after if (is_high_resolution) {. @kovidgoyal or should the multiplication be done outside of scroll_event() so that scroll_event() is called with the already multiplied value?

[kovidgoyal]

I'll look at it when I have a moment

[Luflosi]

What about Linux? X11 and Wayland also seem to be able to return a value from _glfwPlatformGetWindowContentScale() other than 1.

[kovidgoyal]

I have no idea whether the value needs to be multiplied on linux. Lets wait until someone with the requisite hardware reports.

[Luflosi]

Does this help reproduce it on linux for anyone: https://wiki.archlinux.org/index.php/HiDPI ?

[maximbaz]

I'm on Linux with HiDPI screen, but I don't fully understand what's the bug about. When I scroll with touchpad, the scrolling speed is subjectively "okay" 🙂

Are there more concrete steps I could take to reproduce the issue?

The only difference I notice between kitty and sakura terminal regarding scrolling is that sakura is much smoother and pleasant for the eye, because it scrolls by pixels, while kitty scrolls by lines. Not sure if this is something of interest for kitty though.

Sakura:

kitty:

[Luflosi]

When you move your fingers on the touch pad by a certain distance (if you use scroll acceleration, things get a little more complicated) does kitty scroll the content by the same distance as in other programs? You can also try putting yoffset *= global_state.callback_os_window->viewport_y_ratio; at the beginning of scroll_event() in mouse.c and see if the scrolling speed feels better. If that line were to make no difference, you could also try to hardcode the value to 2.0 instead of global_state.callback_os_window->viewport_y_ratio.

[maximbaz]

• behavior on master:

  moving on touch pad by a little scroll by 5 lines (because the default value of wheel_scroll_multiplier is 5)

• behavior with yoffset *= global_state.callback_os_window->viewport_y_ratio:

  exactly the same as on master, moving the same distance on touchpad scrolls by 5 lines

• behavior with yoffset *= 2:

  moving finger on the same distance on touchpad scrolls by 10 lines

[Luflosi]

Ok, so kitty does not seem to think that your hardware and software are able to support high resolution scrolling (is_high_resolution in scroll_event() in mouse.c is false), even though you seem to be able to fully use that functionality in Sakura, else wheel_scroll_multiplier would have no effect. That probably results in kitty scrolling being a bit different than in many other applications anyways. What I also find weird is that viewport_y_ratio seems to be 1 for you, even though you said, you have a HiDPI screen. This means, that kitty does not correctly set that variable.

[maximbaz]

Scrolling is a bit weird comparing to other apps, I've just added GIFs showcasing the difference in the other issue: #1123 (comment)

I have 4k 15" screen, my DPI value is 210, on X11 with i3 on Arch Linux.

[maximbaz]

What I also find weird is that viewport_y_ratio seems to be 1 for you, even though you said, you have a HiDPI screen. This means, that kitty does not correctly set that variable.

Checked this, in case you are curious.

So I have DPI value set to 210 both with xrandr --dpi 210 and in .Xresources as Xft.dpi: 210 and *dpi: 210.

viewport_y_ratio is computed in glfw.c as frameBufferSize divided by windowSize, in my case both values for height equal to 2067 ­— this is how I get 1.

That probably results in kitty scrolling being a bit different than in many other applications anyways.

Comparing to sakura or chromium, scrolling in kitty is much slower when I set wheel_scroll_multiplier = 1. I've also tried a different driver today (synaptics instead of libinput), with this driver kitty still marks my touchpad as "low resolution". However with synaptics driver I can at least configure the scrolling speed (globally) and enable "kinetic scrolling", this helps a bit 🙂

@Luflosi if you ever get to implementing improvements for scrolling, be sure to ping me for testing 😉

[kovidgoyal]

On X11 with high dpi screens viewport_y_ratio is always 1, its the way glfw works. In any case that is irrelevant to the issue, since we would be using pixels reported in the scroll event directly that are pre-multiplied by glfw/X11 for high res screens, so viewport_y_ratio would not be used at all.