MC-122053Mouse wheel/touchpad scroll amount is ignored
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action seems to be treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many releases (as long as I can remember). The scrollable chat history seems to one of the few things that take into account the change amount.
Environment
Windows 7/10 using touchpad or high dpi mouse scroll wheel.
Created Issue:
Mouse wheel/touchpad scroll amount is ignored
UI elements that take scroll input throughout Minecraft don't seem to take into account the scroll wheel/touchpad scroll "change" value (ie when scrolling in a menu/creative menu/hotbar). This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will cause many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many versions.
Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
Environment
Windows 7/10 using touchpad or high dpi mouse scroll wheel.
UI elements that take scroll input
throughout Minecraftdon't seem to take into account the scroll wheel/touchpad scroll"change" value(ie when scrolling in a menu/creative menu/hotbar). This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will cause many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many versions.Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input don't seem to take into account the scroll wheel/touchpad scroll change amount (ie when scrolling in a menu/creative menu/hotbar). This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will cause many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many versions.
Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input don't seem to take into account the scroll wheel/touchpad scroll change amount
(ie when scrolling in a menu/creative menu/hotbar). This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will cause many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many versions.Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will cause many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many versions.
Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will
causemany scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many versions.Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many versions.
Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many
versions.Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many releases (as long as I can remember).
Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many releases (as long as I can remember).
Getting the "change" value in mouse scrolling may or may not have been available in LWJGL 2, but if the GLFW library is being used from LWJGL 3, it is possible to get the change in scroll amount so that it can be taken into account when the hotbar and menus scrolling is used.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many releases (as long as I can remember). The scrollable chat history seems to one of the few things that take into account the change amount.
UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action
is treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many releases (as long as I can remember). The scrollable chat history seems to one of the few things that take into account the change amount.UI elements that take scroll input (ie when scrolling in a menu/creative menu/hotbar) don't seem to take into account the scroll wheel/touchpad scroll change amount. This means that even a very small change value (such as residual velocity from a touchpad "flick", or any input from a high dpi mouse wheel) will trigger many scroll actions, and since every scroll action seems to be treated the same, the menus/hotbar scroll farther than needed (sometimes by a lot). This problem seems to have existed in the game for many releases (as long as I can remember). The scrollable chat history seems to one of the few things that take into account the change amount.
![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
[Mojang] Georgii Gavrichev![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
relates to
relates to
![[Mod] redstonehelper](../../../data/avatars/users/10122.svg){kind=small}
In 1.14 (starting in Pre-Release 2)
In Mouse Settings, toggle "Discrete Scrolling" and set the sensitivity back to 1.
In 1.13 (starting in 18w21a)
Adjust the new mouseWheelSensitivity option that has been added to .minecraft/options.txt. In most cases, setting this to 10 will produce a reasonable hotbar behavior.
18w01a changed how scrolling works. Trying to scroll through hotbar slots is often unsuccessful now. Scrolling in the creative inventory is now very fine-grained, to the extent that it is now possible to change item lines without changing the position of the slider, see attached screenshots.
Scrolling, as observed in the creative menu, doesn't scale linearly with physical scrolling speed either.
I also attached a forced crash report for system info.
Note that this is different from MC-122641, which was introduced in an earlier snapshot.
Likely caused by the fix for MC-122053.
From the comments:
I have been doing some more testing on this issue. My setup is on MacOS 10.13.3 and a Logitech MX Master Mouse with the mouse wheel in "click-to-click" mode (i.e. you can move the mouse wheel one "notch" at a time with feedback.)
Prior to 18w01a, if you were to move the mouse wheel one notch on the hotbar, the selector would move across one slot for each notch.
Since 18w01a, it takes 10 individual notches to register the mouse moving across (it will move over on the 10th notch.) I have tested this by counting the number of individual notched scrolls before the selector will move across to the next slot in the hotbar. This effect happens in either direction.
Analysis
See this comment and this longer write-up.
Timothy Miller's analysis above is close, but it doesn't actually match the data I've been collecting (and after talking with him, he agrees that this superseeds his). Here's my full analysis; you don't have to read the whole thing but do check the first section and the last two sections. The most important bits of it:
- 18w01a fixed
MC-122053by looking at the scroll magnitude values given by LWJGL; before it just looked at the direction. (Note that what theosib said about the magnitude not being reported seems to be inaccurate on windows and mac; a magnitude is present here at least for some mice) - It did that not only for scrollable lists, but also for changing hotbar slots, but also they made it so that for changing hotbar slots, a total scroll amount of 1.0 needs to be hit. This seems reasonable in theory, but there are other issues...
- On windows, a small scroll produces a single event with a small magnitude; for my mouse, it's 1/4th of the full size. Scrolling faster produces some larger events, but scrolling at a constant speed produces events of the same magnitude as per this graph.
- On mac, a small scroll change produces a delta of .100 on LWJGL 3. However, continuing to scroll produces a MAJOR acceleration, as seen in this graph from a mac using a windows-style mouse – from .1 to 10, over a very short amount of time.
- This weird acceleration isn't a bug in LWJGL 3; it can also be seen on LWJGL 2, and also on firefox - it's an inherit behavior on macs, as such.
Why does mouseWheelSensitivity help? Setting it to 10 makes things slightly better, but that's just because it makes it so the smallest reported value from a mac of .100 is treated as 1.0 and thus a hotbar rotation. It doesn't do anything about the acceleration, and isn't a perfect solution.
My recommendation thus is to just eliminate the code from 18w01a that checks for rotations less than 1.0 and adds them, and instead to treat any rotation as sufficient for the purpose of changing hotbar slots (as was the case in 1.12.2). It may make sense to allow configuring whether to ignore the magnitude in various cases as well.