-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduced performance in long line drawing #4731
Comments
Thanks for reporting. I'll see if we can optimize the line self-intersection checks. |
@bhousel is it really that important to do the self-intersection checks at runtime? won't it be enough to do it at save? |
Yes, I think it is important for the user to get immediate feedback that how they are drawing a line is wrong.. Could you imagine if you edited for an hour and then tried to save and found out half your lines were wrong? That would make me so sad 😢 |
If iD could list and let you navigate to the intersection nodes similar to how untagged lines are handled it wouldn't be a big deal to fix the mistakes to my mind. |
@bhousel The current code seems to check the full line for any intersection, which is quite expensive. |
That's true, but I don't think the code knows the drawn segments - D3 clips the line for us. I do think there are probably opportunities to speed this up. Snapping a point to a line is also a similar algorithm, (it projects the point onto every segment), and that one works fast. |
An interesting thing about this is that the slowdown begins at exactly 1k nodes. Raising the figure to 2k which is the general limitation of way length would solve the issue if that is possible. |
There are notable lags when editing long ways (1k+ nodes) as of v2.6.0.
Prior to the update the reduced berformance was observed only when you have that many way nodes unsaved. After the update it is lagging even when you are editing a just saved line.
The text was updated successfully, but these errors were encountered: