Describe the bug
Running the https://github.com/Shirajuki/js-game-rendering-benchmark benchmark actually shows that batching primitive shapes drawing is actually broken in melonJS. for sprite based games, sprite batching is actually working, and primitive batching does not really matter, unless it heavily relies on manually drawing shapes everywhere, but this is still something to be fixed (noticed also the flickering when drawing sprites in the benchmark, which is a side effect of the broken primitive batching).
See the performance drop when count is 2500 or higher, especially for fill operations
Expected behavior
at least maintain 60fps when count is at 2500 stroke of fill operations (even Pixi fps is dropping at 5000 and higher)
Device :
CPU/GPU: M1 Max (for reference on fps count)
MacOS Ventura
Safari 16.3, Chrome 109
melonJS Version: 14.x
Additional context
Proposed solution:
make sure that all primitive drawing use the same type (e.g. gl.LINES, GL.LINE_STRIP, gl_LINE_LOOP) to enable batching :
use different vertex buffer instance for quads (sprite) and primitive drawing. Right now the default compositor "re-use" the Quad Vertex Buffer, leading to a waste of unused data when drawing shapes
talking about the compositor, finally split the compositor into two different ones. One to draw quads/sprites, and one to draw primitives/shapes. This way they can both managed data and batching independently. There was some initial work done but it was never really finished.
Describe the bug Running the https://github.com/Shirajuki/js-game-rendering-benchmark benchmark actually shows that batching primitive shapes drawing is actually broken in melonJS. for sprite based games, sprite batching is actually working, and primitive batching does not really matter, unless it heavily relies on manually drawing shapes everywhere, but this is still something to be fixed (noticed also the flickering when drawing sprites in the benchmark, which is a side effect of the broken primitive batching).
To Reproduce
melonJS
Stroke
ofFill
Expected behavior at least maintain 60fps when count is at 2500 stroke of fill operations (even Pixi fps is dropping at 5000 and higher)
Device :
Additional context
Proposed solution:
make sure that all primitive drawing use the same type (e.g. gl.LINES, GL.LINE_STRIP, gl_LINE_LOOP) to enable batching :
use different vertex buffer instance for quads (sprite) and primitive drawing. Right now the default compositor "re-use" the Quad Vertex Buffer, leading to a waste of unused data when drawing shapes
talking about the compositor, finally split the compositor into two different ones. One to draw quads/sprites, and one to draw primitives/shapes. This way they can both managed data and batching independently. There was some initial work done but it was never really finished.
Any other idea/suggestion, feel free to comment.