Xenon
Xenon is a client-side Fabric mod that reduces the rendering cost of other players when lots of them are on screen. It's aimed at busy servers, events and lobbies where dozens of players are visible at once.
Why crowds are expensive
Every player skin is its own texture, and models with different textures can't be batched into one draw call. Armor pieces, trims, capes, held items and nametags each add more on top of that.
With 200 players in view I counted 961 draw submissions per frame inside player rendering alone, a bit under 5 per player. That's the cost Xenon goes after.
What it does
On by default. Distance is from the camera, and nothing inside 16 blocks is ever touched:
| Beyond | Stops being drawn |
|---|---|
| 24 blocks | Outer skin layer: hat, jacket, sleeves, trouser overlay |
| 32 blocks | Armor trims |
| 32 blocks | Nametags (vanilla keeps drawing them out to 64) |
| 40 blocks | Capes and elytra |
| 48 blocks | Held and worn items |
Nametag culling does most of the work. A nametag is exactly two draw submissions, one for the background quad and one for the text, and neither batches with anything else. At 200 players it accounts for 198 of the 341 draw calls Xenon removes; the distance LOD accounts for the other 143.
Dropping the outer skin layer saves geometry but no draw calls, since the outer layer shares a render type with the body.
Off by default:
- Skin atlas mode copies every loaded skin into one shared 1024x1024 texture (256 slots of 64x64), so players can be drawn together in far fewer draw calls. It works in my testing, but I haven't benchmarked it and it hasn't been tried on a live server, so I'm making no performance claim for it yet. It only handles 64x64 skins and draws them through a translucent render type, which means it can change how players look. If you see wrong skins or flickering, turn it off and open an issue.
When it helps
The savings all come from players past 32 blocks, so what matters is how far away the crowd is, not just how big it is. Open-world PvP, a large event you're looking across, a busy spawn you can see most of.
It won't do much:
- In a packed lobby where everyone's inside 20 blocks. Nothing crosses a threshold, so Xenon does nothing and costs nothing. That's the normal case on minigame servers.
- At 25 to 50 visible players, where I measured 2-6%. Not worth installing a mod for.
- In singleplayer or on small servers.
- If your fps is limited by something else: chunk loading, terrain, shaders, other mods. Xenon only removes time spent inside other players' render calls, which was 21% of the frame at 10 visible players and 72% at 200 in my test scene. On a real server it'll be lower, because networking and world updates are competing for the same frame.
It doesn't touch chunks, the world, or non-player entities.
Benchmarks
| Players | Vanilla fps | Xenon fps | Change | 1% low | Draw calls in player rendering |
|---|---|---|---|---|---|
| 25 | 256 | 263 | +2% | +4% | 134 → 123 |
| 50 | 186 | 197 | +6% | +5% | 267 → 225 |
| 100 | 123 | 150 | +22% | +17% | 521 → 349 |
| 200 | 75 | 100 | +33% | +28% | 961 → 621 |
How these were measured:
- Minecraft 1.21.8, Fabric Loader 0.19.3, Fabric API 0.136.1, Xenon 0.1.0
- Other mods: none besides Fabric API
- Xenon settings: defaults, skin atlas off
- Game settings: render distance 12, Fancy graphics, particles minimal, VSync off, fps cap 260, default dev-client window (I didn't pin a resolution, so treat the absolute numbers as specific to this setup)
- Players: fake player entities spawned client-side by the mod's own benchmark harness, each with a unique generated 64x64 skin and a repeating pattern of gear (iron armor, gold-trimmed diamond armor, elytras, swords, torches, shields). Laid out in a grid 12 to 78 blocks from the camera, walking small circles so limb animation keeps running
- Camera pinned to a fixed position and rotation every tick, in a superflat world with daylight cycle, weather, mob spawning and random ticks all switched off
- Each number is the median of 4 runs, averaging fps over 10 seconds after a 3-second warmup, measured with the profiler built into the mod
- Every run measures Xenon on and off in the same client session about half a minute apart. Comparing separate launches on this laptop is useless: the same config gave me 274 fps and 155 fps half an hour apart
- The whole matrix was run twice, 8 runs total, once measuring Xenon-off first and once measuring it last. Whichever variant runs later in a step picks up a warmup advantage worth as much as 28 points on its own, so each figure above is the mean of the two orders. At 100 and 200 players the two orders agreed to within 0.7 of a point
- Hardware: Intel Core Ultra 9 285H, Intel Arc 140T integrated graphics (driver 32.0.101.8991), 32GB LPDDR5X, Windows 11, on AC power, Balanced power plan
The draw call counts aren't estimates. All 8 runs reported the same numbers to the decimal, so that column is exact.
To reproduce: benchmarks/run-matrix.sh 4 forward, then 4 reverse, then node benchmarks/analyse.mjs, which prints every table above including the per-run spread. Raw CSVs are in benchmarks/data/. Full write-up, including the runs that showed no benefit and everything I haven't measured, is in BENCHMARKS.md.
Your results will depend on your GPU, resolution and how many players are actually in view. This is an integrated GPU at a small window size, which is about the most favourable case for a mod that removes CPU-side draw work. On a dedicated GPU at a higher resolution the gain will likely be smaller. I haven't tested a discrete GPU, AMD or NVIDIA drivers, Linux, macOS, shader packs, or a real server.
Setup
Settings are in config/xenon.json, and every feature has its own toggle. Distances are adjustable too, with a 16-block floor so you can't configure it into changing how nearby players look. With Mod Menu installed there's also a config screen for the toggles.
Commands: /xenon status, /xenon toggle, /xenon reload, /xenon hud.
/xenon hud is the useful one if you want to check what it's doing on your own hardware: it shows players rendered, draw submissions, and what the LOD dropped that frame. Watch it with the mod toggled off and on.
Compatibility
Xenon has no dependency on any other mod and runs fine with none installed.
Sodium, Lithium, FerriteCore, ModernFix, Entity Culling and ImmediatelyFast don't overlap with anything Xenon changes, and it leaves all its features on when it sees them. Entity Culling in particular pairs well: it skips players you can't see, Xenon makes the ones you can see cheaper. That said, none of the benchmarks above had another optimization mod installed, and I haven't tested every possible combination.
A few mods do conflict with specific features, so Xenon switches off just that feature and logs a line saying why. It never disables itself wholesale and never fails on a conflict:
- 3D Skin Layers: outer skin layer LOD. That mod renders the outer layer as real geometry, so it owns it.
- Entity Texture Features / Entity Model Features: skin atlas. Both swap entity textures or models at bind time, which a naive atlas would get wrong.
- Iris / Oculus: skin atlas. Shadow passes re-bind textures and I can't guarantee the rewritten UVs survive them.
If Xenon misbehaves next to something, switch off the one feature rather than uninstalling. /xenon status will tell you what's currently active.
Minecraft 1.21.5 to 1.21.8, Fabric, client only. Nothing is required on the server.
