Bugzilla

Caching the path makes sense (wherever it is used, both on the compositor and the main thread if need be). I'm not very familiar with most of the code under the layout/ but Matt Woodrow and Markus Stange among others would have more educated opinions on the topic.

If you need to further optimize this, note that we currently build a flattened version of the whole path, and then traverse it to find a specific position along. We could:
 - Not build the flattened path and have the flattening code just measure distances instead of generating a path.
 - Build an array of "check points" for example which would give us for a given path event where we are (position and advancement along the path), so that we can fast track to the last check-point before the advancement we are looking for and then only do the flattening approximation from there (this only makes sense if you are already caching the path).
In case you are interested in these optimizations, I have something that resembles the first one in a side project of mine: https://github.com/nical/lyon/blob/master/algorithms/src/walk.rs (I haven't implemented the second one). Until now path flattening was not performance sensitive in Gecko because it was only used to position text along a path so I never bothered to port that over to Gecko.
Anyway, caching is certainly more important than these two optimizations cand you can add them on top if need be.

Caching the path makes sense (wherever it is used, both on the compositor and the main thread if need be). I'm not very familiar with most of the code under the layout/ directory but Matt Woodrow and Markus Stange among others would have more educated opinions on the topic.

If you need to further optimize this, note that we currently build a flattened version of the whole path, and then traverse it to find a specific position along. We could:
 - Not build the flattened path and have the flattening code just measure distances instead of generating a path.
 - Build an array of "check points" for example which would give us for a given path event where we are (position and advancement along the path), so that we can fast track to the last check-point before the advancement we are looking for and then only do the flattening approximation from there (this only makes sense if you are already caching the path).
In case you are interested in these optimizations, I have something that resembles the first one in a side project of mine: https://github.com/nical/lyon/blob/master/algorithms/src/walk.rs (I haven't implemented the second one). Until now path flattening was not performance sensitive in Gecko because it was only used to position text along a path so I never bothered to port that over to Gecko.
Anyway, caching is certainly more important than these two optimizations cand you can add them on top if need be.