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

[Calinou]

@MightyPrinny Can you (or anyone else) still reproduce this bug in Godot 3.3.2 or Godot 3.4beta3?

If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

[paxer]

3.3.4 stable

I have the same issue reproduced on Windows 7 and Windows 10 machines, slightly better performance on macOS Big Sure, but still noticeable. The Path2d which I test has about 50 points, and with every new duplicated object the performance of editor gets significantly worse in the area of the scene where these objects added.

Note: this is not an issue when the game starts, it is only when scrolling/working with the scene where the Path2D object added, so seems like the editor issue

[lawnjelly]

Just to note that rather than fix this in the rendering we can presumably alternatively reduce the number of line segments in the curves of the Path2D (assuming this is just a gizmo?).

I'm just having a look at simply converting canvas_item_add_line calls to draw_polygon calls for lines of more than 1.0 width. This seems to be working, because polygons can be batched and large lines cannot. The only thing is it cannot use anti-aliasing, so in order to get this speedup we'd have to turn off anti-aliasing for drawing the Path2D. But this is only for gizmos anyway, so that may be a fair trade off.

Ok done some more investigation. This screenshot is zooming in on a section of Path2D in the editor. It shows that in the situation before the segments are drawn as separate thick lines, using anti-aliasing. The anti-aliasing is giving a lighter outline, presumably because the color is inheriting some alpha, and it is effectively drawing these areas twice.

You can also see the edges don't match up between these segments don't match up. I noticed this when drawing them as lines, but maybe this would be better drawn as a polyline, and perhaps the polyline can be decomposed to polys in the same way.

[akien-mga]

Fixed by #54377.