This regressed with https://github.com/ppy/osu/pull/20850 because the
function was used in other places which expect it to factor slider
velocity into the equation.
Rather than reverting, I've added a new argument, as based on the method
naming alone it was hard to discern whether SV should actually be
considered.
The reason for the change in #20850 was to avoid the SV coming in from a
reference object which may not have a correct SV in the first place. In
such cases, passing `false` to the function will give the expected
behaviour.
This is a nuanced detail that was implemented incorrectly from the
outset. When mapping, generally a mapper chooses the distance spacing
with no regard to the SV. It has always been common to have a lower
or higher distance spacing than SV, but with the way the lazer editor
has worked, the SV was multiplied into the distance snap grid display,
incorectly changing its spacing depending on the "reference object"
(which is usually the previous hitobject chronologically).
Scroll speed is not saved and doesn't affect gameplay.
It is purely a feature for a better visualization.
It is currently bind to scroll speed increase/decrease.
Default F3/F4 crashes with editor shortcuts so it has to be changed.
Until now, toolbox scroll areas would block input from arriving behind
them, even when no visible element was clicked.
In addition, clicking on a button inside a toolbox would still send a
`MouseDown` event to things behind it. Specifically, the editor's
`HitObjectComposer` would receive these events and also place objects
when the user does not expect them to be placed.
This fixes another regression that occurred due to `ScrollContainer`s no
longer blocking input theirselves.
