Revert "Update scaling math to land on 100% consistently." #8048
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reverts #8043
I only tested this after merging. Unfortunately it breaks the canvas scaling for some input devices. How broken it is depends on magnitude and frequency of the input device's scroll events.
As implemented in the PR, once the scale has snapped, you have to scroll more than the threshold in a single scroll event to "break" the snap.
This interacts badly with certain input devices. For example, on a macOS touchpad, individual scroll events are very frequent with a small magnitude. It takes a really strong scroll for a single scroll event delta to be greater than the threshold.
So if you scroll hard enough to break the snap, it almost instantly jumps to the next snap point, thanks to the inertial nature of macOS touchpad gestures. Even without the inertial touch stuff, on some input devices you would need to be very agile and quick to not accidentally scroll directly from one snap point to the next.
One way to implement the snap behaviour might be to handle scrolling while snapped and not snapped differently: