Move tool rubberbanding

[VLD280]

Description

When using the move tool to relocate a feature, the feature is offset from the mouse pointer, and it rubberbands as it follows the mouse pointer, making it difficult to move objects precisely. When you select a feature, right click, and select the move tool, the feature will try to maintain the same distance from the mouse cursor as the distance between where you right clicked and where you clicked to select the move tool. When you move the mouse, the object tries to follow the cursor, but the offset is elastic. The object movement will hitch and lag, then accelerate toward the cursor and over shoot. Sometimes it gets completely stuck for a second or two, then jumps to the cursor. This unpredictable movement makes positioning features precisely annoying. This occurs with all 3 types of geometry.

Screenshots

trimmed_Screen.Recording.2024-09-10.at.4.51.08.PM.mp4

trimmed_Screen.Recording.2024-09-10.at.5.21.08.PM.1.mp4

Version

2.4.0-pre.0

What browser are you seeing the problem on? What version are you running?

Firefox v130.0

The OS you're using

mac

Steps to reproduce

1. Select a feature
2. right click to open context menu
3. select the move tool
4. move cursor
5. moving the cursor at different speeds produces variations in behavior.

The browser URL at the time you encountered the bug

https://rapideditor.org/canary#map=19.54/39.07587/-108.48348&background=MCGIS-County-Valleywide-Imagery-2024&datasets=fbRoads,msBuildings&disable_features=boundaries&id=n-1

The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0

[bhousel]

I agree that frame rate looks pretty bad. I see you've got a really huge screen too, so I imagine the GPU is working pretty hard to draw everything. I do wonder whether Chrome might perform better?

[bhousel]

I did some profiling of the code and tried editing and moving features around #map=19.54/39.07587/-108.48348 but I didn't see anything obviously bad, and it performed pretty ok for me on Chrome 128, though it could be better.

Screen.Recording.2024-09-11.at.5.23.40.PM.mp4

It looks like you're experiencing similar slowdowns from #1145 .
You might have some luck trying the suggestions on that issue about changing the WebGL backend (whether Firefox is using Metal, I don't know).

[VLD280]

Thanks for looking into the issue! I will try to find some time to do a little more experimenting and check out some of the suggestions. Just from day to day experience, I do feel like the current version of Rapid performs better in Chrome. I have also experienced other memory/render intensive applications struggling more in Firefox.