Godot: Path2D renders slowly

[MightyPrinny]

Godot version:
3.2.2 beta 2 (and previous versions)

OS/device including version:
MXLinux 19 64 bits

Issue description:
Path2D nodes draw very slowly, 3d paths don't slow down the editor so much for me

Steps to reproduce:
Add a Path2D and draw a path

[clayjohn]

Could you provide more information?

Are you saying that having a Path2D node in the scene slows down your FPS? Or are you saying that the process of drawing a Path2D slows down the editor?

Also some numbers would be helpful. For example if your FPS goes from 2500 to 2050, that isn't very bad, but if a single Path2D takes FPS from 500 to 50, then that is a big issue.

[MightyPrinny]

A single visible path 2d node can slow down the editor considerably more than any other 2D node, here's a video.

https://streamable.com/4ws2n9

Maybe drawing lines in general is slow, but paths seem to have a bigger impact in the editor performance.

[clayjohn]

Thanks for the video! But could you provide numbers please? The FPS of the video is low enough that I can't see an appreciable difference.

[MightyPrinny]

The video is 60fps(I think it's 30fps if you play it at 360p), the part where I just duplicate some sprites is 60fps all the time and when I add the path it drops to like 20, I'm not sure how to measure the fps in the editor I'll try to figure it out to post numbers

[lawnjelly]

Can confirm it is slow, just tried a test and a similar number of path points dropped FPS in a project to 73fps, whereas sprites will be >1000 fps with batching.

Thick lines are quite involved, they involve drawing a central rect and 4 smoothed GL_LINES round the outside. I'll see if I can break out the mac_lines branch so I can compare it with just drawing the lines as rects.

[MightyPrinny]

I measured the fps in game with visible navigation turned on and I got 2300fps with nothing on the screen at a very low resolution, when the path is visible it drops to 90.

In the editor in distraction free mode fps is 60 with nothing on the scene (vsync) and it drops to 14 when the path is visible.

[lawnjelly]

Just for info, when I used my mac_lines branch and force off the GL_LINES, the FPS goes from 73fps to 460fps. The difference is partly the standard thick lines use 5x as many drawcalls.

Also long thin triangles / lines are bad for rendering:
http://fragmentbuffer.com/gpu-performance-for-game-artists/

Similarly, long thin triangles are bad for performance for another reason beyond quad usage: GPUs rasterize pixels in square or rectangular blocks, not in long strips. Compared to a more regular-shaped triangle with even sides, a long thin triangle ends up making the GPU do a lot of extra unnecessary work to rasterize it into pixels, potentially causing a bottleneck at the rasterization stage.

There's also something weird going on with the drawcalls. For around 30 line segments, I'm getting 1240 drawcalls. Even with 5 drawcalls per line that would be closer to 150 drawcalls. Yes .. for circa 30 line segments it is trying to draw 248 lines for some reason. Multiply 5 and you get the 1240 drawcalls.

Ah .. the Path2D is made up of curves, which presumably are broken into line segments, hence the large number of primitives. So in a way this is totally expected, it will probably only be properly solved in this case when we extend the batching to other primitives such as lines.

[iustin-nita]

I have the same problem on a 2018 Macbook pro running Catalina. FPS go to 12-14 both in editor and in-game using GLES2