Cache or optimize triangulation data used for drawing with fill operation

[obiot]

the current Path2d triangulatePath() method :

melonJS/src/geometries/path2d.js

Lines 55 to 78 in bb2c020

	triangulatePath() {
	var i = 0;
	var points = this.points;
	var vertices = this.vertices;
	var indices = earcut(points.flatMap(p => [p.x, p.y]));
	// pre-allocate vertices if necessary
	while (vertices.length < indices.length) {
	vertices.push(pool.pull("Point"));
	}
	// calculate all vertices
	for (i = 0; i < indices.length; i++ ) {
	var point = points[indices[i]];
	vertices[i].set(point.x, point.y);
	}
	// recycle overhead from a previous triangulation
	while (vertices.length > indices.length) {
	pool.push(vertices[vertices.length-1]);
	vertices.length -= 1;
	}
	return vertices;

does not cache the generated data, forcing melonJS to recalculate every thing when using directly method like fillRect() and friends, and create a huge performance bottleneck.

For reference here below is an extract from a benchmark on fill operation for both rectangle and circle:

melonJS 15.0.0 (M1 Max)	Fill (rect)	Fill (circle)
500 op/s	60 fps	60 fps
1000 op/s	60 fps	32 fps
2500 op/s	35 fps	12 fps
5000 op/s	16 fps	6 fps
10000 op/s	6 fps	4 fps
15000 op/s	4 fps	3 fps

which shows performances dropping when drawing more than 1'000 shapes per frame.

[obiot]

Perfomance gain :

• fillRect — ~90% faster. Was: path2D.beginPath (pool releases) + rect (4x moveTo/lineTo = 8 pool allocs) + earcut + flatMap. Now: 6 property assignments on pre-allocated objects.

• fillEllipse (r=50) — ~80% faster. Was: beginPath + ellipse (~125 points, ~125 pool allocs, trig) + earcut O(n log n) on 125 points + flatMap. Now: same trig but directly into triangle fan, no pool, no earcut, no flatMap.

• fillArc — same ~80% win as ellipse, scaled to arc size.

• fillPolygon — depends on whether the shape changes. Static polygon (common): ~95% faster after first frame (earcut cached via getIndices()). Dynamic polygon: similar to before since earcut must re-run.

• fillRoundRect — ~75% faster. Was: beginPath + 4 lines + 4 arcTo (each generates arc points) + earcut on ~58 points. Now: direct geometry, no pool, no earcut.

• The stroke method optimizations (batched joins, redundant setCompositor removal) are maybe ~10-20% wins on the stroke path — smaller but they add up.

Overall for a typical scene mixing fills and strokes, we could expect a 2-3x faster for WebGL primitive rendering. The benchmark from the issue showed circle fills dropping to 6 fps at 5000 ops — with the triangle fan approach that should stay closer to 30-40 fps since earcut was the main bottleneck.