There was a large change in the mouse scroll wheel sensitivity since Logic 2.4.45. Where it used to be “one wheel click is one zoom level” on my mouse, I now have to spin it extremely aggressively to change the zoom level. It takes basically the entire throw of the wheel, 6-8 clicks on mine, to get it to zoom one step. This has to be done rapidly, and it’s rather difficult to pull off consistently. Otherwise it doesn’t zoom at all.
I have confirmed this is true in 2.4.45, 2.4.46, and 2.4.47 preview. Zoom scrolling was normal in 2.4.44 and all releases before it for several years, and reverting to 2.4.44 “fixes” it. Zooming with a touchpad remains unchanged.
This is more disruptive than it may sound – my workflow for years was entirely based on rapid zoom-out/zoom-in across very long traces, which is now not really possible with a mouse. Furthermore, the capture file format changed, so I can’t remain on 2.4.44 and open captures saved by my coworkers running 2.4.46.
Is this a known bug and/or fixable and/or are there any settings or environment overrides I can use to control the sensitivity?
environment: Arch Linux, kernel 7.1.6, X11 (xorg 21.1.24), libinput 1.31.3, Razer Deathadder V3 mouse. Every other application, including other Electron-based apps, still respond with one-wheel-click-is-one-scroll-step.
Sorry for the trouble with this. This is a bug in how our software detects the difference between a track pad and a physical mouse wheel - they require vastly different scaling to feel smooth and consistent.
Windows
@Sebastian the Windows answer is short - we found the issue and fixed it internally, it will be in the next release. The TLDR is that we updated electron, which changed how mouse wheel events are reported. We compensated for this, but we missed something - if you change the windows font size setting, it breaks scroll. In the short term, I recommend either keeping 2.4.44 or making sure the Windows accessibility font size setting is 100%.
If it’s already 100%, please let me know, and I’ll email you a special debug build of the software which will spit out all the information we need to debug. Even if if it’s 100% right now, the fix we already have should still fix your problem.
@trevor this is the first report we’ve heard of this on Linux. We’ll need to collect some more data. I’ll email you with a download link to an internal build of the software, that has a built-in debugging tool for analyzing wheel events and screen scaling. I’d like you to check to see if the issue is fixed, then use the debug feature to send me a report with more details.
Basically, we need to detect the difference between track pads (specifically high resolution trackpads that support smooth scrolling) and physical mouse wheels. The events have a large difference in magnitude, so we need to scale them differently, plus we want to animate scroll events from a physical mouse wheel (there are a few “smooth” scrolling mice - these have high resolution wheel events. we treat these like track pads, which works well. They are pretty rare though). These events come from chromium (our UI is web based) and they come pre-scaled by the system’s DPI scale factor, and on some platforms, they are also scared by the in-app zoom level. Our recent releases updated the version of chromium we use, and the way these values are computed changed. We compensated for this before we released the software, but we didn’t realize that Chromium is now accounting for even more OS settings - including the accessibility font size on Windows. However we didn’t think we had an issue on Linux. (We tested Linux over a wide range of UI scale factors) It’s likely there is another factor we missed.
A bit ironic - we actually correctly compensated for the issue we’re seeing on windows, however what we did not anticipate was rounding error passed to us from chromium that only exists when the accessibility font size isn’t 100%. If the issue on Linux is similar - Rounding error from Chromium - then our fix should cover that platform too.
@trevor I’ve just sent you an email from our support system using the email you have registered with this forum. If you don’t get the email, please either reply here or contact us through support.
I can confirm that, due to using a 4K screen, my Windows display settings are to scale text and apps by 150%. Looking forward to the fix in the next release!
Windows display settings are to scale text and apps by 150%
Just to make sure I’m clear - there are 2 scale settings I’m aware of in Windows:
Display Scale
This is on the System > Display settings page, and looks like this on Windows 11:
We’ve extensively tested this setting with our software, and have no known issues with it. I run my machine at 150% scale full time, and test 100%, 125%, 150%, and 200% with our software.
It sounds like you’re talking about the “System > Display” “Display Scale” setting is 150%. This is pretty common, and as far as we can tell, doesn’t explain the issue on its own.
If you haven’t already, could you check the accessibility text size setting?
To find the actual value, you need to hold you mouse over the slider, the percentage is shown in the Tooltip:
If that shows 100%, let me know. I’d like to collect more data if that’s the case. It’s still very likely our fix will solve your problem for you, but we would not have a root cause in this case, so any help we could get would be appreciated. At a minimum, it would be worth finding out if the fix solves the problem for you.
If the accessibility text size is set to 150%, then our fix will probably fix it for you. Also, we can just test that ourselves. (I’ve only tested 110% accessibility font size so far)
On the Linux side, it turns out that I had zoomed the whole interface out sometime in the distant past and forgotten about it. That’s “Decrease Font Size” (Ctrl+-) from the View menu, putting my interface at zoom level 0.8.
Only that one interface zoom level, 0.8, has problems with the mouse scroll wheel. Changing the interface zoom level to anything else fixes it, so that’s an easy workaround for anybody else who has this problem.
I also tested an insider build provided by @markgarrison, and the scroll wheel works correctly on all zoom levels there, so it’ll probably be fully fixed in an upcoming release.
@trevor, thanks for finding that! That sounds like exactly the same rounding issue that’s been introduced with the new chromium/electron version, which is what that build I sent you fixes.
@Sebastian, you’re the second confirmed case if this problem on someone with a 150% screen and but without text size scaling. I have no idea why you can reproduce this, but I can’t, and most users can’t, even at the same scale factor. However, we already ran the same test with the other user in this configuration and confirmed the fix still holds, so I think we should be safe.
We should have the fix out by the end of the month at the latest, hopefully sooner. Sorry for the delay on this!
