FastPackLoad
Faster resource pack loading, and no more freeze when you join a server with a big pack. Client-side only, no Fabric API needed.
Описание
FastPackLoad
Vanilla does a lot of unnecessary resource pack work on the render thread. With a large server pack that shows up as a multi-second freeze when you join or switch servers, sometimes long enough for Windows to grey the window out as "not responding".
FastPackLoad removes most of that work.
What it changes
Pack discovery runs in parallel. Vanilla opens every pack and parses its metadata one at a time, on the main thread, before the loading screen even appears.
Zip packs are indexed once. Vanilla walks the whole archive every time a reloader asks about a resource folder, rebuilding and decoding every entry name on each pass.
Font work comes off the render thread. Glyph coverage is resolved across cores, and with hundreds of fonts it is resolved by a different algorithm entirely. A warm-up loop that only does anything for TrueType fonts is skipped when a pack has none.
Atlas mipmaps are generated across cores. Vanilla builds every sprite's mipmaps in a single task on one worker, while the rest of the reload pool has nothing to do.
The loading screen stops waiting around. A finished reload still sits through a grace period and a fade, up to three seconds of nothing. That one is a behaviour change, so it has its own switch.
A vanilla race is fixed. The lazy ZipFile handle in the pack reader is unsynchronised,
even though a reload reads packs from several threads at once. That can leak a file handle
per race, or hand a reader an archive another thread just closed, which surfaces as
IllegalStateException: zip file closed part-way through loading.
Measured
On a server whose pack ships 746 font providers:
| before | after | |
|---|---|---|
| Render thread frozen | 4384 ms | 448 ms |
| Full reload | ~7.2 s | ~3.7 s |
Your numbers will differ. Packs that are light on fonts have less to gain.
When it still freezes
A watchdog samples the render thread and, if frames stop arriving, logs the stack it is stuck in, along with the package that stack points at. Every reload also logs a short summary of what blocked and for how long, so a slow pack can be pointed at instead of guessed about.
Notes
Client-side only; nothing is required on the server. No Fabric API dependency. Every change
can be switched off individually in config/fastpackload.json if you need to rule something
out.