The response of editing massive point pages is too slow

[raopengfei]

I encountered the problem of a large number of dead points in page editing when using the latest leaf-geoman version. I tried to solve the problem in the demo and found that the enableGlobalEditMode method parameter passed
options: {limitMarkersToCount: 20, allowSelfIntersection: false, allowSelfIntersectionEdit: false},
However, the editing of the page is still very difficult. After the performance analysis of Chrome, the hasSelfIntersection method in the L.PM.Edit.Line file is too long. After the analysis of the code, this is the logic to judge the self intersection. It should be called after the allowSelfIntersection parameter and allowSelfIntersectionEdit parameter. The writing method referring to the _onMarkerDragStart method is better than the _onMarkerDragEnd method, In addition, the hasSelfIntersection method is also called in its method, such as the handleLayerStyle method Please refer to the screenshot for the specific execution time. I think you should review the method call check and judgment.
My English is poor. I hope you can understand my description. Thank you.

[Falke-Design]

If I understand you correctly, you suggest to move the hasSelfIntersection() call into _onMarkerDragStart. We can't do this, because we need to check after moving a vertex, we need to check if there is now a intersection.

But I think we should calculate self intersection only if allowSelfIntersection is false. I will create a fix in the next days.

[raopengfei]

Thank you for your reply. Your last remark is correct. Before calling the hasSelfIntersection method, you need to check that the parameter allowSelfIntersection is true, but this is not the case in the _onMarkerDragEnd method and the handleLayerStyle method. Under multi-point conditions, it can reduce a lot of performance overhead.

[905807873]

I have confirmed that the allowSelfIntersection parameter is true. The current page has tens of thousands of points. When the editing function is called, the animation cannot run smoothly, and the editing function is also affected by the performance problem

_2024_11_14_17_36_56_687.mp4

[905807873]

I've found a workaround for this, {allowSelfIntersection: true, snappable:false } The edit function allows to pick up the vertices of other layers by default, although it is helpful to edit, but when the number of layers is too large, it will lead to too much calculation, snappable parameter can be changed to false, thank the author for providing the tool, thank you

[raopengfei]

Optimizing this code can significantly improve the performance of editing massive amounts of line and surface data. As I mentioned in the screenshot above, hasSelfIntersection will take more than 8 seconds to execute, severely blocking the browser's rendering. Options. allSelfIntersectionEdit=false should no longer be used for judging self intersection logic. The root cause of the problem is the lack of effective adjustment of the order of judgment conditions in _onMarkerDragEnd.

You can rudely add a judgment in the hasSelfIntersection method to solve it

We hope it will be helpful to you.