Mouse scrollwheel extermely slow w/ Mac Sonoma 14.4.1

[ghidra1]

Scrolling with mouse scrollwheel has become extermely slow w/ Mac Sonoma 14.4.x

Any displayed content which requires scrolling (e.g., webpage) is almost unusable. Seems to be on the order of 1-pixel for every complete turn of the wheel. On Mac the Mouse Options... Scroll speed is set to max.

Client:
Amazon Linux 2 (AWS Workspace)
TigerVNC 1.13.1
downloaded from GitHub release page

Server:
Mac Sonoma 14.4.x (bare metal)
VNC Server: Mac Screen Sharing enabled w/ Remote Login

[samhed]

From your description, it sounds like things have gotten worse with macOS 14.4.x?

Have you always used AWS workspace as client? How does that work? I assume you have to use some sort of remote-connection, what solution do you use to access the AWS workspace?

[ghidra1]

We primarily use the AWS Client app to access the workspace then from there we use TigerVNC to access bare metal Mac. I could try jumping through another Linux system first and see if anything changes. Interestingly, it seems that a Terminal session on the Mac scrolls fine but other apps such as Chrome and Finder do not.

[lf94]

I'm encountering the same thing, Arch Linux

[CendioOssman]

Do you have the same setup, @lf94? In that you connect via the AWS Client first?

[lf94]

Nope, I just connect directly to the Mac Mini M1 machine!

[CendioOssman]

Great! That simplifies things, and we can rule out any bugs in AWS.

Are you also seeing the problem in just some applications?

And what are your client details?

[harry-dickson]

FYI RealVNC exhibits the same behavior. I am also connecting to a Mac Mini locally.

Feels like it is scrolling pixels not lines, which is quite RSI inducing. The option on Mac to always show scrollbars helps me.
Suggestive that some kind of scaling factor is missing/incorrect for Mac 🤷‍♀️

[ghidra1]

Issue is pimarily when using web browser (i.e., Chrome)

[lf94]

Im seeing it in any app.

[Mike4Online]

I am seeing this, too. I'm using the latest TigerVNC Client (downloaded 2 days ago) on a Windows 10 64-bit system to connect to macOS Sequoia 15.1. Affects all applications.

[mensfeld]

Same here ;(

[ghidra1]

It's been 9-months and no response from project team :( Is it possible to get some feedback on this issue. It is taking its toll on productivity - I spend too long trying to scroll windows.

[ItEndsWithTens]

I'm not using TigerVNC, but for what it's worth I have the same problem in UltraVNC 1.4.3.6, and stumbled over this thread searching for info. My symptoms are identical to the OP, in that Terminal scrolls perfectly well but Chrome and Finder windows are slow as molasses, regardless of OS pointer options.

I'm connecting from a Windows 10 Pro 64-bit machine, over my local network to a headless Late 2014 Mac mini, running Sequoia 15.2 by way of OpenCore Legacy Patcher 2.2.0. The system had previously run macOS 12, Monterey, and scrolling through VNC was fine. Initially I did of course suspect that my using OCLP to run macOS on unsupported hardware was the problem, until my research led me here.

Worth noting might be something I found today: a discussion thread on the Devolutions forum that describes a similar issue, and mentions two additional scroll events that the ARD protocol adds beyond the base RFB ones. Having read that, I tried installing the free edition of Remote Desktop Manager and found the changes referenced in that post seem to have worked. RDM is a bit clunky to set up, but once I did I found I could connect to my Mac and scroll all windows just fine, Terminal, Finder, and Chrome alike.

All that would seem to suggest it's not one individual remote client to blame, but the mysteries of the protocol itself, which I guess changed some time after Monterey? All the various remote client devs end up with the problem in their laps, obviously, but it doesn't seem unique to TigerVNC, if that's of any reassurance.

[CendioOssman]

Thanks for all the testing. It unfortunately sounds like a server bug. Which makes it difficult for us to do anything about.

It might be possible to work around the issue if someone figures out those secret Apple scroll events. Or if Devolutions would share what they've figured out.

Until then, I'm afraid there isn't anything we can do here.