jonobr1
commented
1 year ago Thanks for posting your question. Two.js can render lots of paths at the same time. Its SVG renderer renders all shapes as <path /> elements regardless of its primitive. So, the number of points or objects in the scene is as much a bottleneck of the browser as it is with Two.js. That being said, what you've outlined is an extremely ambitious technical challenge.
Multiple rendering modalities can certainly help and you would need to construct multiple canvases to make something like this performant for the various use cases you've described. Very interested to see the demo and also curious why you started with paperjs if it only renders to canvas.
We've been building a web app using paperJS specifically for lasso painting and have hit a wall. After about a thousand path objects, which sounds like a lot but is not when you're painting, the app slows down tremendously. We're looking at ways to improve the performance and have considered using two.js. While the desired output is SVG, users will be able to export as rasters as well. However, we want to maintain the ability to select, delete, transform the path elements in addition to giving the user the control to rasterize vs doing it for them. Additionally, we want to maintain visual clarity as much as possible, and raster gets funky when you scale it.
I've run some tests with the examples from your site, the zoom/pan and the particle generator, and it seems like two can handle many svg paths. However, that's just rendering the same shape, not custom shapes with varying points per shape. How does Two handle this situation? I see that it's render agnostic, so could we tap into hardware acceleration?
Example I have a hosted example I can share but it's not public yet. I'd be happy do DM it to whomever is interested in helping with this
Screenshots
Environment (please select one):
If applicable:
Desktop (please complete the following information):
Smartphone (please complete the following information):