Batch custom shape draw calls (fills, and borders of additive shapes)

[fa7ad]

Hi, a heads-up before anything else: these changes were written by Claude (LLM/AI), not by me, and I don't know the projectM codebase at all. I've tested them visually and checked the frame rate, but I can't vouch for them beyond that. If you don't take AI-generated contributions, or would rather not review code from someone who can't fully explain it, please feel free to close this outright. No hard feelings.

Background

I'm building a small native macOS frontend for libprojectM 4.x for personal use and experimentation here. These patches came out of chasing slow presets there.

Problem

CustomShape::Draw() makes at least one draw call per instance, and shapes can have up to 1024 instances. On macOS, where OpenGL runs on top of Metal and each draw call is expensive, that cost dominates:

• Fills: one draw (plus a buffer upload) per instance.
• Borders: each border flushes the fill, then draws once per outline pass (4 passes with thickOutline), with a buffer upload each time. A 1024-instance thick-outlined shape ends up at about 5,000 draws per frame.

Changes

1. Fills (835a16e): consecutive instances that share a blend mode and texturing go into one indexed triangle list and are drawn with one call. Borders still flush the batch first, so the draw order doesn't change.
2. Borders of additive instances (3ced1dd): additive blending gives the same result in any order, so these borders, including the 4 thick-outline offsets, go into a line list drawn right after their fills. Non-additive borders keep the exact per-instance order.

Results (Apple Silicon, macOS):

• A fill-heavy preset went from about 15 to about 58 fps.
• suksma - 3125 bad attempts2*.milk (1024 instances, thick additive borders) went from about 5 to 60 fps.
• I saw no visual difference, but I only compared by eye.

Things I'm unsure about

• Order changes for additive borders: the result should be identical up to floating-point rounding, and with an 8-bit target, clamping at each step gives the same result.
• The outline batch uses GL_LINES with GL_LINE_SMOOTH, like the existing per-instance GL_LINE_LOOP. I haven't checked the GLES builds.
• I have no idea whether this fits how you'd want the renderer structured.

Thanks for projectM!

[kblaschke]

Oh, the shape draw call count, yes, this issue was something we'd have to get into.

From a first glance, the change looks okay to me. If draw order, blending and texturing are properly honoured, it shouldn't result in any visual differences.

There is an issue with the code though: It uses C++17 features (std::optional), which we cannot use because libprojectM is built with C++14 to improve compatibility. This has to be replaced with a C++14-compatible implementation before this can be properly tested.

[kblaschke]

Code must compile with C++14, but uses C++17 features.

[fa7ad]

Thanks for taking a look, I'll push an update targeting C++14 when I get some time (probably over the weekend) :)