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 hit area for detecting mousemove seems to be very sensitive (not to mention potential FPS drops), so the crop handles can easily become desynced from the mouse position
CleanShot.2022-08-24.at.16.48.19.mp4
I know this is a limitation of building in the browser, where mousemove events stop as soon as the mouse exits the hit area, but I wonder if
we can make the hit area the entire browser window — currently it stops at the bounds of the CropArea, which means when you start cropping from the edge you can often "lose grip" of the handles
Long term, change the implementation to be "absolute", storing the start mouse position on mousedown, and just checking the delta of the current mouse position compared to the starting position on mousemove. I've found this to feel better UX wise (and better for lower framerates) than accumulating the delta per event.
The text was updated successfully, but these errors were encountered:
The hit area for detecting mousemove seems to be very sensitive (not to mention potential FPS drops), so the crop handles can easily become desynced from the mouse position
CleanShot.2022-08-24.at.16.48.19.mp4
I know this is a limitation of building in the browser, where mousemove events stop as soon as the mouse exits the hit area, but I wonder if
mousedown
, and just checking the delta of the current mouse position compared to the starting position onmousemove
. I've found this to feel better UX wise (and better for lower framerates) than accumulating the delta per event.The text was updated successfully, but these errors were encountered: