LightOccluder2D polygons cause editor slowdowns

[HaSa1002]

Godot version

3.3.3.stable
3.4.beta4

System information

Windows 10
GLES3,
Ryzen 7 3700X,
32GB RAM

Issue description

LightOccluder2D polygons slow the editor down even with small polygons. (And my computer is not a potato)

2021-09-15.15-00-53.mp4

Steps to reproduce

1. Open gear2.tscn
2. Select LightOccluder2D (<- slowdown starts here)
3. Pan the canvas

Minimal reproduction project

Slow LightOccluder.zip

[Calinou]

Can you try running a C++ profiler to see where the slowdown comes from?

[HaSa1002]

Yes, I can hook VS into Godot once I am done with my current task

[lawnjelly]

Could well be similar to #38543, possibly issuing a large number of drawcalls to draw the preview.

[akien-mga]

Could you check if #54377 fixes it? I tested locally and couldn't reproduce the slowdown before this PR either, so I can't confirm.

[HaSa1002]

Tested on v3.5.beta.custom_build.4cae48d81 and issue is still noticable. Though not so extreme (just a feeling. May be incorrect)

[HaSa1002]

I can share the diagsession with someone if there is interest. I just don't want to post it here. I don't see anything suspicious. (OK my GPU get's one fire...)

[lawnjelly]

It's okay shouldn't need the project. I tried the min reproduction project again, and compiled it so the occluder debug draws even outside the editor, so I could diagnose the frame with the batching.

canvas_begin FRAME 554
items
	joined_item 1 refs, 
			batch R 0-1 [0 - 152] {255 255 255 255 }
	joined_item 1 refs, 
			batch P 0-138 {255 255 255 255 } MULTI
canvas_end

This is the output, so the debug drawing is the second, as a polygon all in one drawcall.
Looking at the calling code, this may be the same as before the PR above, so the drawcalls is not a problem, it's drawing everything in just 2 drawcall.

			PoolVector<Vector2> poly = occluder_polygon->get_polygon();

				if (poly.size()) {
					if (occluder_polygon->is_closed()) {
						Vector<Color> color;
						color.push_back(Color(0, 0, 0, 0.6));
						draw_polygon(Variant(poly), color);
					} else {
						int ps = poly.size();
						PoolVector<Vector2>::Read r = poly.read();
						for (int i = 0; i < ps - 1; i++) {
							draw_line(r[i], r[i + 1], Color(0, 0, 0, 0.6), 3);
						}
					}
				}

So not immediately sure why it might be slow. 🤔

BTW, if you have a different scene that is not using a closed poly, that would have been using lots of draw_lines, and that could be different (and the PR should speed that up). But I'm just going by the MRP.

[HaSa1002]

Could that be a driver issue? I mean the 3060 TI should be able to draw this poly. On the other hand the core usage of main thread goes up to 100%

[lawnjelly]

Possibly, it's strange behaviour, if it's with the MRP. If you are able to use a CPU profiler, and you find a load of time is spent in the driver, then that sees like a culprit.

Some things you could try if that was the case:

• Turn off batching in the editor (rendering/batching/options/use_batching_in_editor) and restart. The legacy may use a different draw method (although I'm not sure it may be the same for polys, but worth a try)
• In rendering/2d/openg there are 4 settings for the dynamic buffer usage. You could try tweaking them for your system, you may have some joy.

[HaSa1002]

load of time is spent in the driver, then that sees like a culprit.

Idk tbf. I could try to update my driver.

Turn off batching in the editor (rendering/batching/options/use_batching_in_editor) and restart. The legacy may use a different draw method (although I'm not sure it may be the same for polys, but worth a try)

Did that. No change.

In rendering/2d/openg there are 4 settings for the dynamic buffer usage. You could try tweaking them for your system, you may have some joy.

will try

[Penjami]

@HaSa1002 Did you end up finding what was the cause for the problem? I'm having similar performance issues with the LightOccluder2D. Hard to draw a polygon, when it gets super laggy after drawing about 15 vertices.

[Calinou]

This comment still applies, by the way:

Can you try running a C++ profiler to see where the slowdown comes from?

(Please post results of profiling here by taking screenshots of the profiler you're using.)

[Penjami]

Here is a couple of screenshots from running the profile for about a minute while modifying a LightOccluder2D polygon:

With godot.windows.tools.64 filter:

And without:

[lawnjelly]

That does look like it's spending a lot of time in the driver (DrvValidateVersion seems prominent, and some sleeps and waits, which might be indicative of stalls). Very little CPU time spent within Godot itself (the audio driver is normally a false flag when profiling, as it has to keep up the audio output rate through the audio callback, irrespective of the relative speed the app is running).

It's occurred to me that as well as the regular batching, when an occluder is active there's also some extra paths active outside the regular batching canvas renderer - canvas_light_shadow_buffer_update() which I've no idea how efficient this is.