You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, I believe the only way to unite multiple paths is to unite them one by one into a single compounded path.
let combined = new this.paper.CompoundPath(null);
for (const item of paths) {
combined = combined.unite(item, {insert: false});
}
However this is memory inefficient because each call to unite will clone both the item being merged and the combined compound path which contains all previous paths in it. Its not quite O(n^2) in terms of memory allocation but it is bad.
Link to reproduction test-case
The main problem that we ran into was uniting a paragraph of text that had been outlined to paths. This sketch tries to reproduce the issue by creating 100 copies of a single word. The test can take upwards of 12 seconds to run and uses around 460mb of memory.
I was able to modify the internal traceBoolean function to specify if it should call preparePath on the inputs. Then I added a new function called PathItem.uniteList that would call preparePath beforehand and then reuse the results for each call to traceBoolean. This was able to reduce our internal test down from 40-60 seconds to 4 seconds with a much smaller memory footprint.
Description/Steps to reproduce
Currently, I believe the only way to unite multiple paths is to unite them one by one into a single compounded path.
However this is memory inefficient because each call to unite will clone both the item being merged and the combined compound path which contains all previous paths in it. Its not quite O(n^2) in terms of memory allocation but it is bad.
Link to reproduction test-case
The main problem that we ran into was uniting a paragraph of text that had been outlined to paths. This sketch tries to reproduce the issue by creating 100 copies of a single word. The test can take upwards of 12 seconds to run and uses around 460mb of memory.
Sketch
Expected result
I was able to modify the internal
traceBoolean
function to specify if it should callpreparePath
on the inputs. Then I added a new function calledPathItem.uniteList
that would callpreparePath
beforehand and then reuse the results for each call totraceBoolean
. This was able to reduce our internal test down from 40-60 seconds to 4 seconds with a much smaller memory footprint.The changes that were made can be found here.
Let me know if you would like to see a pull request made for this issue and I can work on getting the code cleaned up and test cases made.
The text was updated successfully, but these errors were encountered: