FastPackLoad

# 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.