Vertices one batch may hold before the run is split, unless a caller says
otherwise.
A cap is needed at all because the planner's arrays grow to the largest run
they are asked for and never shrink: without one, a scene of 100 000 sprites
sharing an atlas would allocate a single 400 000-vertex staging buffer, and a
backend would then upload it as one buffer object. 65 536 is chosen for two
reasons — it is the vertex count above which indices stop fitting in 16 bits
(this planner emits 32-bit indices, but a backend that wanted narrow ones
could split on the same boundary), and it bounds the staging arrays at
65 536 × 9 floats ≈ 2.4 MB in the widest layout.
Splitting costs one draw call per 65 536 vertices, which is 6 draws for
§86's 100 000-sprite row instead of 100 000.
Vertices one batch may hold before the run is split, unless a caller says otherwise.
A cap is needed at all because the planner's arrays grow to the largest run they are asked for and never shrink: without one, a scene of 100 000 sprites sharing an atlas would allocate a single 400 000-vertex staging buffer, and a backend would then upload it as one buffer object. 65 536 is chosen for two reasons — it is the vertex count above which indices stop fitting in 16 bits (this planner emits 32-bit indices, but a backend that wanted narrow ones could split on the same boundary), and it bounds the staging arrays at 65 536 × 9 floats ≈ 2.4 MB in the widest layout.
Splitting costs one draw call per 65 536 vertices, which is 6 draws for §86's 100 000-sprite row instead of 100 000.