You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The zooming behavior is a bit too finicky. It is quite easy to accidentally reverse the direction when trying to stop the zoom, for example.
The way zooming works, roughly, is that it checks how many scroll events (coming from the mouse wheel, for example) were generated over a recent time frame, and computes a zoom speed based on that. If it detects a scroll event that goes into the opposite direction as the current zoom speed, it will stop the zoom.
The design intent here is to provide appropriate control over the zooming behavior over a wide range of situations:
You are zoomed in closely, but want to zoom out quickly to get an overview? Turn the mouse wheel quickly to generate a fast zoom.
You are inspecting some detail of the model, and need to control the zoom very precisely? Zoom slowly by turning the mouse wheel slowly, and stop that zoom exactly where you want, by given the mouse wheel a turn in the opposite direction.
I think this design intent can be achieved using the current approach, but it needs some tuning to feel good. All input is handled in fj-viewer, and zooming specifically is done in zoom.rs. Using a completely different approach that realizes the same design intent would also be a perfectly acceptable resolution to this issue.
Please also note that there is a related issue (#25) that is specifically about zooming speed. It might make sense to tackle both issues concurrently.
The zooming behavior is a bit too finicky. It is quite easy to accidentally reverse the direction when trying to stop the zoom, for example.
The way zooming works, roughly, is that it checks how many scroll events (coming from the mouse wheel, for example) were generated over a recent time frame, and computes a zoom speed based on that. If it detects a scroll event that goes into the opposite direction as the current zoom speed, it will stop the zoom.
The design intent here is to provide appropriate control over the zooming behavior over a wide range of situations:
I think this design intent can be achieved using the current approach, but it needs some tuning to feel good. All input is handled in
fj-viewer
, and zooming specifically is done inzoom.rs
. Using a completely different approach that realizes the same design intent would also be a perfectly acceptable resolution to this issue.Please also note that there is a related issue (#25) that is specifically about zooming speed. It might make sense to tackle both issues concurrently.
Labeling https://github.com/hannobraun/Fornjot/labels/good%20first%20issue, as the code that governs zooming lives in a single file, making this a pretty focused issue that doesn't require any knowledge of Fornjot specifics.
The text was updated successfully, but these errors were encountered: