Optimize row distance filter

[TrevorBurgoyne]

the distance filter needs some updating:

• use new drawing
• fewer calculations?
• investigate clashes with delete_polygon mode
  • drawing polygon is very laggy, and each new delete polygon un-deprecates previously deleted items

[joshua-dean]

Some debouncing on the calculations could alleviate a lot of visible lag for certain operations.

As for optimizing the calculations themselves, that could be tricky depending on the usage. What do the most laggy interactions look like? Is it a large amount of points mostly inside/outside the filter range, or different characteristics? I'd be open to putting together a synthetic testing dataset (to store along with the demo data) for development/benchmarking purposes.

[TrevorBurgoyne]

Some debouncing on the calculations could alleviate a lot of visible lag for certain operations.

As for optimizing the calculations themselves, that could be tricky depending on the usage. What do the most laggy interactions look like? Is it a large amount of points mostly inside/outside the filter range, or different characteristics? I'd be open to putting together a synthetic testing dataset (to store along with the demo data) for development/benchmarking purposes.

yeah lots of points and lots of lines it gets pretty bad, drawing new lines or adjusting the filter value is very slow.

[joshua-dean]

yeah lots of points and lots of lines it gets pretty bad, drawing new lines or adjusting the filter value is very slow.

Predominantly inside the desired range, outside, or evenly distributed? Most approaches I'm thinking of are grouping-based, to include/discard whole groups of points in a single calculation. If the majority of the points tend to be included it might be a bit different than if they're mostly excluded.

[TrevorBurgoyne]

yeah lots of points and lots of lines it gets pretty bad, drawing new lines or adjusting the filter value is very slow.

Predominantly inside the desired range, outside, or evenly distributed? Most approaches I'm thinking of are grouping-based, to include/discard whole groups of points in a single calculation. If the majority of the points tend to be included it might be a bit different than if they're mostly excluded.

most points are included, the general use case is to exclude outlier points. however there is also some redundancy since some points may be filtered by the confidence slider, and i think the row distance filter iters through all of those as well. maybe points that are filtered out by a specific slider should be stored in a separate location

[joshua-dean]

most points are included, the general use case is to exclude outlier points. however there is also some redundancy since some points may be filtered by the confidence slider, and i think the row distance filter iters through all of those as well. maybe points that are filtered out by a specific slider should be stored in a separate location

deprecated_by and then some sort of "deprecation hierarchy" might be future proof - a simple set of configurable rules for which deprecation processes are allowed to overwrite other ones.