ParticleContainer vs Container: handling per-particle texture swaps without breaking batch rendering

Goal

Render 20,000–50,000 similar entities (particles, tiles, or sprites) at 60 fps while allowing a small subset (≈1–5 %) to change their visual appearance at runtime by swapping to a different texture from the same atlas.

Constraints and uncertainty

Container preserves full per-sprite transform flexibility and lets any child change its texture freely, but incurs one draw call per child, which exceeds the frame budget at this scale. ParticleContainer collapses the entire batch into a single draw call when all children share the same baseTexture, yet the current implementation silently drops any child whose texture points to a different baseTexture until the container is rebuilt—no event, warning, or automatic re-batch occurs. Rebuilding the container (or toggling autoResize) reallocates the geometry buffers and stalls the frame. The migration guide suggests flattening the hierarchy and using a texture atlas, but does not address the case where a minority of particles must temporarily show a different atlas frame that lives on a separate baseTexture.

Specific questions

1. Is there a documented pattern—such as a secondary ParticleContainer layer, a custom shader, or a texture-atlas layout strategy—that lets a few particles switch baseTexture without rebuilding the primary batch?
2. If a rebuild is unavoidable, what is the measured overhead of ParticleContainer buffer reallocation for 50 k sprites on typical desktop GPUs, and does autoResize: true amortize this cost acceptably?
3. Does the interaction manager’s hit-testing remain accurate on the primary ParticleContainer while a secondary container handles the texture-swapping particles?