Slow rendering with a large number of Paths

[Austin Small]

Hi,

In my Paper project I have some layers with a large number of Paths (ex: layer 2 below). If I move around the paths in layer 1, the rendering is quite slow. Due to the separation of the layers, I would expect Layer 1 to be unaffected by the number of paths in Layer 2.

In the short-term I have reduced the severity of the issue by rasterizing Layer 2 while dragging Layer 1. However, this still presents a poor user experience due to the time it takes to rasterize Layer 2, and has resulted in a lot of complex and unmaintainable code in our codebase.

I am wondering if it is possible to optimize Paper JS in a way that manipulating Layer 1 can happen quickly (regardless of the number of paths in Layer 2) without needing to rasterize Layer 2.

I'm not sure if this is the right forum to mention this, but since this behavior is important to my project, I'm willing to donate meaningfully to Paper JS in order to prioritize this issue.

Best,

Austin

[PaperJSnewProgrammer]

This slow rendering in paperjs is a well known side effect of browsers screen redraw. They basically redraw the whole screen at every small change. The authors know about the problem but have declined to hire programmers to work on the project. The quote I read by Jürg Lehni  was that even hiring a programmer represented a time hit that in supervising the programmer and getting them up to speed. (I hope I have that mostly correct from memory).

I'm wondering if it would be somewhat simpler hack to turn off automatic screen redraw and have it update at slower intervals. This would require a custom version of paper though, and might be more appropriate for a local install.

Also there's a some a "simplify" function - (not sure that's the correct) that eliminates points, that might be worth a try. I'm wondering if anyone has done a writeup on proposed or successful solutions for the "slowdown" problem.