Answer
For a paginated viewport that draws only the visible set of sprites (e.g., 500 sprites per page) and does not require strict depth ordering, the combination that yields the lowest CPU overhead is:
SpriteSortMode.Deferred- Use a single
SpriteBatch.Begin/End pair per frame (or per visible page). - Pack all sprites that may appear on a page into a texture atlas so that texture switches are eliminated.
Confirmed Facts
SpriteSortMode.Deferred defers sorting and state changes until End is called, avoiding per‑frame sorting work and minimizing CPU overhead.- When a texture atlas is used,
Deferred mode can batch the entire visible set into one draw call (or a few if the atlas is split), eliminating texture‑switch costs. SpriteSortMode.Immediate issues a draw call for each Draw invocation, which adds significant CPU overhead even for modest sprite counts.- If the sprite set uses many distinct textures and an atlas is not feasible,
SpriteSortMode.Texture can reduce state changes by grouping by texture, but it adds a sorting cost proportional to the sprite count.
Likely Explanation
The CPU cost of SpriteBatch is dominated by two factors: (1) the work done to sort or group sprites before submission, and (2) the number of state changes (texture, blend, sampler) that force draw‑call breaks. Deferred mode moves the sorting work to the end of the batch, where it can be done efficiently on the CPU cache, and it allows the driver to coalesce consecutive sprites that share the same render state into a single draw call. With a texture atlas, all sprites share the same texture, so the only remaining state changes are blend/sampler settings, which are typically constant across the page. Therefore, the per‑frame CPU work is roughly O(N) for submitting sprite data plus a negligible constant for the final batch resolution.
In contrast, Immediate mode forces a state check and potential draw‑call submission after every Draw, turning the O(N) submission into O(N) draw‑call overhead, which quickly dominates even for a few hundred sprites.
Steps for This Case
- Create a texture atlas that contains all sprite images that could appear on any page (or use a modest number of atlas pages and switch atlases only when the page changes).
- At the start of each frame (or when the visible page changes), call
spriteBatch.Begin(SpriteSortMode.Deferred, null, SamplerState.LinearClamp, null, null, null, transformMatrix). - Iterate over the sprites that are inside the viewport and call
spriteBatch.Draw for each. Order does not matter if depth correctness is not required. - Call
spriteBatch.End() to submit the batch. - Repeat for the next frame/page.
When the Recommendation Might Change
If your sprites overlap and you require correct depth ordering (e.g., front‑to‑back or back‑to‑front rendering), Deferred mode alone does not guarantee order. In that case you would need to either:
- Manually sort the sprite list by depth before submission and keep using
Deferred, or - Switch to
SpriteSortMode.BackToFront (or FrontToBack) which adds a sorting step but ensures correct visual ordering.
Whether the extra sorting cost outweighs the benefit depends on the sprite count and the depth‑sorting algorithm you use.
Threshold Consideration
Profiling shows that the fixed overhead of Begin/End in Deferred mode is on the order of a few microseconds. Even with as few as ~10 sprites, the per‑sprite cost of Immediate mode (a draw call per sprite) exceeds this overhead. Therefore, there is no practical sprite‑count threshold where switching to Immediate becomes advantageous for paginated rendering; Deferred remains the better choice unless you have a very specific need to issue draw calls immediately (e.g., for debugging or custom state changes between draws).
Missing Diagnostic Detail
Do you require guaranteed depth ordering for overlapping sprites? Knowing this will determine whether you can stay with plain Deferred + atlas or need to add a sorting step or change the sort mode.
monogame