ctrl + scrollwheel zooms in and out by a factor of 1600% every scroll wheel tick

• Sep 22, 2021 - 13:00
Reported version
3.6
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Few
Severity
S3 - Major
Reproducibility
Once
Status
PR created
Regression
No
Workaround
Yes
Project

OS: Arch Linux w/ KDE Plasma
Reproducible with both the musescore package in the arch official repository and also the appimage.

EDIT: found the Mouse zoom precision setting, setting it to 16 (the highest it'll go, the default is 6) results in a 283%
zoom instead of a 1600% zoom, more usable but still not ideal. This is still a bug yeah? Attempting to make th e setting go above 16 by editing MuseScore3.ini did not work (nice job on not allowing settings to be busted like that)

For whatever reason, (and this bug started in the last couple days). Whenever zooming with ctrl+scrollwheel zooms in or out by a factor of 1600%, rendering the (quite useful) feature useless. Ctrl+scrollwheel up zooms in to 1600% then to 25600%, and zooming out takes me to 6%. I'm not even sure if there was an update since when this broke so I'm thoroughly confused as to what could have happened. This bug report is thus a stab in the dark to see if anyone else is experiencing this. No other programs exhibit this behaviour. Here's an except from the logs:


unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 1600% (rounded from 16.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 100% (rounded from 1.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 6% (rounded from 0.062500)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 100% (rounded from 1.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 1600% (rounded from 16.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 25600% (rounded from 256.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 40000% (rounded from 400.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 2500% (rounded from 25.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 156% (rounded from 1.562500)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 10% (rounded from 0.097656)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 156% (rounded from 1.562500)


Comments

Status active needs info

FWIW, it works normally for me on Debian, and I haven't heard of other reports of this on Arch. Since it appears you are saying this only started recently, it seems likely to be connected to some specific setting on your particular system, as opposed to general MuseScore issue. but if anyone can find steps to reliably reproduce this on other systems, please let us know!

For the record, on my system, the factor is around 12%, and in fact is likely the sixth root of two more precisely, because it takes six "clicks" to reach 200% - and it does reach 200% exactly.

No issues for me. OS: Ubuntu 21.04, Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021370, revision: 3224f34 running KDE Plasma 5 desktop.

Like Marc, 6 clicks goes from 100% to 200%; 6 more clicks to 400% etc. so 24 clicks from 100% to 1600%. (and going the other way, 6 clicks from 100% to 50%, 6 more to 25% etc.).

In reply to by underquark

As mentioned in the original post, I set the value to 16, from 6, and whilst the issue got better, it still wasn't what you'd call 'usable'. Problem's still there by the way. Don't know where it came from, don't know when it's going, don't know where it came from, cotton eye joe. My headcanon is that a cosmic ray went and flipped a bit in one of my config flies, which one I have no idea.

Regardless of what's causing the problem, is there a way to increase the mouse zoom precision beyond 16?

The same thing is happening on my machine: Manjaro 21.1.4; Xfce 4.16; Musescore 3.6.2-2. At precision 16 the factor here is 2.83x, at precision 6 it's 16x. Problem won't be due to changes to Musescore because I last updated it Sep. 13, and the problem only started after a system update today.

I tried a few programs, and none of them have the same issue. So far I tried:
* Gimp 2.10.28
* LibreOffice 7.1.6.2.0+
* Okular 21.08.1
* TeXstudio 3.1.2
* Viewnior 1.7

Sep. 30 update: found a similar issue on Inkscape 1.1.1 (3bf5ae0d25, 2021-09-20). The zoom factor is actually twice the one set in the preferences there. I originally thought it may have been a problem with Qt, but in this case it might be some other reason.

Regression Yes No

I am getting the same issue on Arch Linux and have found out the culprit is the package xf86-input-libinput. On 2021-09-19 it was updated from 1.1.0 to 1.2.0 which sparks the problem. This is also why only rolling release distros are affected as of now, most distros won't have this update for a while.
This update added some functionality for hi-res scrolling which apparently caused problems on multiple ends (for example https://gitlab.freedesktop.org/libinput/libinput/-/issues/681 ). QT also has some problems with it as mentioned here:
https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues…

It seems clear to me that this is not a bug in musescore. I'm hoping for a change in libinput or QT, until then the easiest workaround would probably be downgrading xf86-input-libinput to 1.1.0.

Workaround No Yes

See above:
It seems clear to me that this is not a bug in musescore. I'm hoping for a change in libinput or QT, until then the easiest workaround would probably be downgrading xf86-input-libinput to 1.1.0.

Workaround No Yes

If you didn't downgrade to that, you haven't tested the workaround. How to downgrade is nothing the MuseScore forum can tell you. Ask in a Debian forum.

the problem occurs with every mouse in MuseScore only, no other application shows that behavior of the mega zoom, the behavior of ctrl and + is strange too, the zoom factor is normal, but it scrol everything to the right, till the score is not in sight anymore. probably its a libinput thing, but sooner or later every distro is getting 1.2 and yeah... maybe adopt to that upcoming problem instead of saying downgrading is the solution ? couse the behavior of something has changed obviously.... krita, blender, firefox, inkscape and so on have no problem with zooming. just musescore. Its better to take an serious eye on it now, then later when everyone goin to have that problem don`t you think ? :)

See the articles linked above. Apparently the issue happens with any programs built with the same version of Qt as MuseScore. The next version of MuseScore will be built with newer versions of Qt and presumably won’t have the issue (feel free to help us test a nightly build). But for now, with the current version, rolling back to an earlier version of the input library is the known solution.

Severity S4 - Minor S3 - Major
Status closed active
Type Graphical (UI) Ergonomical (UX)
Priority P1 - High

OK, thanks for letting us know. I've reopened this so it can be looked at to see if there are workarounds we should be trying to employ in our code while we wait for the libinput folks to fix the bug for real. Looks like their proposed fix has been merged into their code but who knows when it will start showing up in any particular Linux distributions.

Well, that PR is s for the 3.x branch, but there won't be a further 3.x release. So that change needs to get made for the master branch to have a chance being included in MuseScore 4

I wasn't aware that PRs to the 3.x branch aren't really useful at this point. But the the same change works for version 4, just in a slightly different place. I updated the above PR to now apply that to the master branch.

If someone still wants to have the change for version 3 to self-compile, it's still up here.