Community listing page, reviews here may not be monitored by the author.
FastPackLoad
No reviews yet
Faster resource pack loading, and no more freeze when you join a server with a big pack. Client-side only, no Fabric API needed.
Community voices
Reviews
No reviews yet. Be the first to review this project!
Get it on
Available Platforms
Compatibility
Supported Environments
Runs entirely on the client. Works on vanilla servers.
About
Project Details
For authors
Embed Badge
If you're the author of this project, you can embed a live badge anywhere that supports HTML or Markdown. It updates automatically whenever ratings change.
Use HTML for any page that supports it, or Markdown for README files and Markdown-based descriptions.
Identifiers
Platform IDs
Resources
External Links
About
Description
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.
Screenshots
Gallery
Versions
Files
Relations
Project Relations
More like this
Similar Mods
Suggestions use data such as tags, dependencies, dependents, descriptions, titles, and more to rank how much they overlap with this mod.
On ModDex
Community snapshot
By the numbers
Statistics
Want to reach Minecraft players?
We're looking for a server hosting partner to feature here and other parts of the site. Interested? Send us a message!
Get in touchGet it on
Available Platforms
On ModDex
Community snapshot
By the numbers
Statistics
Resources