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

Answer to the Specific Questions

1. Pattern for minority texture swaps
   • Keep the bulk (≈95–99 %) of sprites in a single ParticleContainer that references the primary atlas. The container batches all children into one draw call as long as every child points to the same BaseTexture.
   • Move the 1–5 % of sprites that need a different BaseTexture into a second ParticleContainer (or a plain Container if interactivity is required). Layer it above or below the main container using zIndex or addChildAt.
   • Because the secondary container has its own batch, you add only one extra draw call. For a small subset the cost is negligible.
   • Alternative: pack every frame—including the rarely used ones—into one large atlas. This keeps a single ParticleContainer but may increase texture size.
   • Advanced: a custom WebGL 2 shader that samples a texture array or uses bindless textures can render multiple base textures in one pass, but it is not part of the built‑in PixiJS API.
2. Rebuild overhead
   • Reallocating the geometry buffers for 50 k sprites (≈200 k vertices, ~3–4 MB) typically costs 1–4 ms on a mid‑range desktop GPU (e.g., GTX 1060 / RTX 3060). The spike occurs when autoResize triggers a power‑of‑two resize.
   • With autoResize: true the buffer grows geometrically (≈2×). The cost is confined to the resize boundary; subsequent frames are cheap.
   • If you rebuild every frame for even a few particles, the cumulative cost will exceed the 16 ms budget for 60 fps.
   • Pre‑allocating with a fixed maxSize (if the particle count is bounded) removes the resize overhead entirely.
3. InteractionManager hit‑testing
   • Children of a ParticleContainer do not support interactive or hitArea by default, so InteractionManager will not register pointer events on them.
   • To keep hit‑testing accurate for the swapping subset, place those sprites in a lightweight Container (or a second ParticleContainer if you still want batching) and set interactive: true on the individual sprites.
   • Alternatively, implement a custom GPU‑based picking pass; this is outside the scope of the built‑in API.

Practical Steps

1. Primary batch (all particles that stay on the main atlas):

const mainAtlas = PIXI.BaseTexture.from('atlasA.png');
const mainContainer = new PIXI.ParticleContainer(50000, {
    scale: true,
    rotation: true,
    uvs: true,
    alpha: true
});
mainContainer.baseTexture = mainAtlas;
// add 49 500 sprites here

2. Secondary batch for swapping sprites (small minority):

const swapAtlas = PIXI.BaseTexture.from('atlasB.png');
const swapContainer = new PIXI.ParticleContainer(2500, {
    scale: true,
    rotation: true,
    uvs: true,
    alpha: true
});
swapContainer.baseTexture = swapAtlas;
// add 1 250 sprites that need the alternate texture

3. Layering (add the containers to the stage in the desired order):

app.stage.addChild(mainContainer);
app.stage.addChild(swapContainer); // or addChildAt(swapContainer, 0) to render below

4. Pre‑allocate buffer size to avoid resize spikes:

mainContainer.maxSize = 50000;
swapContainer.maxSize = 2500;

5. Interaction (if needed):

const interactiveLayer = new PIXI.Container();
interactiveLayer.interactive = true;
interactiveLayer.addChild(swapContainer); // only if swapping sprites must be clickable
app.stage.addChild(interactiveLayer);

Diagnostic Question

Do the particles that change texture also need to respond to pointer events (e.g., clicks or hover)? If so, a plain Container for the swapping subset (instead of a ParticleContainer) will be required to preserve interactivity, which adds a second draw call for those sprites but keeps the primary batch untouched.