Currently it is very slow to iterate over the bézier segments in some VectorData (which we do a lot). This is because for each segment we iterate over, we must find the start and end position by resolving the PointId. This is done via linear search; it is slow when there are a large number of points and segments e.g. in the red dress demo artwork.
Instead of storing a PointId, the segment domain should store a usize index. This speeds up the common usecase of iterating over some segments, at the cost of having to update the indexes whenever a point is inserted or deleted. This tradeoff seems worthwhile given that we are already running into performance limitations of the current approach.
In order to facilitate procedural editing, the system of point ids will be kept. Optimisations for the path modification node can be done seperately.
Currently it is very slow to iterate over the bézier segments in some VectorData (which we do a lot). This is because for each segment we iterate over, we must find the start and end position by resolving the PointId. This is done via linear search; it is slow when there are a large number of points and segments e.g. in the red dress demo artwork.
Instead of storing a PointId, the segment domain should store a usize index. This speeds up the common usecase of iterating over some segments, at the cost of having to update the indexes whenever a point is inserted or deleted. This tradeoff seems worthwhile given that we are already running into performance limitations of the current approach.
In order to facilitate procedural editing, the system of point ids will be kept. Optimisations for the path modification node can be done seperately.