Geometry2D.offset_polygon() returns too many points

[ImamuraCross]

Tested versions

-Reproducible in:

• v4.3.stable.mono.official [77dcf97]
• v4.3.stable.official [77dcf97]
• v4.3.rc1.official [e343dbb]
• v4.3.beta3.official [82cedc8]
• v4.3.dev6.official [89850d5]

Not reproducible in:

• v4.3.dev5.official [89f70e9]
• v4.3.dev4.official [df78c06]
• v4.3.dev3.official [36e943b]
• v4.2.2.stable.official [15073af]

System information

Godot v4.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 32.0.15.6603) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

Issue description

Normally, using Geometry2D.offset_polygon() w/ JOIN_ROUND on, say, a square polygon produces the following; you can see the number of total points is 48:

However, as of v4.3.dev6.official [89850d5], it produces the following; a point count of 5316:

I am using the same code for both examples:

func _ready() -> void:
	var poly : PackedVector2Array = [Vector2(0, 0), Vector2(500, 0), Vector2(500, 500), Vector2(0, 500)]
	polygon = Geometry2D.offset_polygon(poly, 100, Geometry2D.JOIN_ROUND)[0]

---

I assume that before, it had some way of determining the optimal, minimum point count for performance reasons; now, it seems to cram in as many as it can, which certainly looks nice, but has MASSIVELY affected performance in several areas of my project.

I'm unsure if this is a bug, or intentional; I can see in the changelog, a mention of, "Add closest_points_between_segments() basis path tests for Geometry2D (GH-48652)," but reading the thread, I can't say for sure if its relevant.

If it is intentional, a way to indicate to Godot that I'd like it to decide the optimal, minimum number of points to be used, would be appreciated.
I believe draw_arc() has something to that effect, for instance.

Steps to reproduce

Simply open the MRP; the Geometry2D.offset_polygon() script on the Polygon2D node will run automatically in the editor.

Minimal reproduction project (MRP)

polygon_test.zip

[kleonc]

Duplicate of #97964, already fixed by #98017. Hence closing.

The change was not intentional, it is a regression from #90153. The fix is included in v4.4.dev4.official [36e6207], and marked to be cherry-picked into 4.3 (so should be included in the next 4.3.x release as well).

Note that the result for the provided example is slightly different now, in v4.4.dev4.official [36e6207] it produces 52 points instead of the previous 48 (basically different results from Clipper2 and Clipper1).