Texture Atlas Optimization: Where the Frame Drops
A mobile game scene grows in iterations: first a dozen objects per level, then a hundred, and the frame time budget quietly stops adding up.
Frame drops on low-end devices and long level loading are almost never related to scripts or logic — in the projects we analyzed, the cause is more often how the mobile game texture atlas is assembled.
A typical mistake is one large sheet for an entire resource category: UI, environment, and effects sit together, and the engine loads the whole sheet into memory for the sake of two or three needed elements.
At the same time, build size grows: part of the sheet is not compressed, some channels remain lossless, and decoding a large image takes a noticeable share of level startup time.
Sloppy formatting also hurts separately: elements without padding at the edges, different alpha channels in one sheet, mixing resources with different required detail levels.
On low-end devices this produces jagged edges and repeated unloading-loading of the sheet where loading a single fragment would have been enough. Texture atlas optimization starts not with packing, but with a profile: what actually appears on screen and when.
We capture this profile on target devices, then split sheets by scenes and visibility groups, select a compression format for the sheet contents, and add mip levels where the object recedes into the depth of the frame.
We assemble the build in the same order as yours — a packer such as TexturePacker is connected as an automation step so that manual sheet editing does not return to the project. We explain how this is closed out.
What Repacking Mobile Scene Atlases Gives You
A properly assembled atlas primarily reduces build resource size: repeating elements and small images are packed into shared sheets, duplicates and extra padding at the edges go away.
A noticeable share of source data disappears from the build, and with it the time for unpacking and integrity checks on first launch.
Scene loading time is reduced through two effects: fewer files need to be opened and read, and less data is decoded during transitions between screens.
On a mid-range device the difference is noticeable to the user — the readiness screen does not hold them for extra seconds, and background loading of the next scenes does not compete with rendering the current one.
Device memory usage drops predictably: one large sheet instead of dozens of small ones reduces storage and switching overhead, and a unified storage format eliminates constant releases and repeated loads.
This is the headroom that remains for graphics on budget models and determines whether the scene survives to the end without forced unloading.
Frame stability improves directly: the fewer material switches per frame, the smoother the rendering time and the less frequent the drops at peaks. Out-of-memory failures, which usually surface in long sessions, go away along with splitting resources into many small files.
The result is checked against four measurable signs: build weight is lower, the scene loads faster, memory is used more economically, and frames run smoothly without dips.
If at least one point has not moved, the atlas repacking should be redone — based on measurements, not feelings.
Packing and Compression Modes: Comparison of Approaches
Mobile game resources run into two constraints: video memory size and the number of material switches per frame.
The packing and compression mode is chosen not “to taste,” but according to the atlas contents — gradients, small UI icons, and full-screen backgrounds behave differently.
Lossless compression preserves every pixel, but in memory such a texture still expands fully — the gain remains only in build size.
Block lossy compression (ASTC) keeps data compressed directly in the accelerator memory: size and bandwidth drop, but artifacts appear on thin lines and gradients.
| Option | When it fits | Limitations |
|---|---|---|
| Lossless | UI, fonts, masks, previews | Expands fully in memory, does not save video memory |
| Block lossy | Large backgrounds, material maps | Artifacts on gradients, block multiple requirements |
| Splitting into pages | Atlas does not fit the device limit | More material switches per frame |
| Dense packing with rotation | Heterogeneous sprites, clear grid | Rotation breaks nine-slice elements and shaders |
Packing density conflicts with splitting into pages. The denser the atlas, the fewer pages and switches, but sprite rotation breaks nine-slice elements and shaders that depend on coordinates. Splitting, on the contrary, simplifies art support but adds switches per frame.
That is why we do not lock in a single mode: UI and fonts go lossless, large backgrounds use block compression, and overfilled atlases are divided by co-occurrence frequency. The profile is fixed in the build script, and new art does not break the layout.
Work Order: From Measurement to Project Handover
We repack the atlas not “by eye,” but based on measurement results: first we capture a profile on target devices and find exactly what is bottlenecking — texture block occupancy, video memory usage, draw call count, or scene loading time.
Then follows a sequence of steps where each decision relies on data from the previous one, not on the developer’s habit.
- Measure bottlenecks. We profile problematic scenes and menus on a representative sample of devices — from low-end to high-end. We record baseline metrics: frame time, memory consumption, loading duration, material switch count.
- Atlas splitting scheme. We group sprites by how often they appear together in a frame and by shared material, calculate the area budget and padding allowance between elements so we do not catch edge bleeding on mip levels.
- Repacking and rebuild. We assemble atlases according to the approved scheme, bring sizes to values convenient for compression, update bindings in resources, and verify that the build passes without manual edits.
- Verification on target devices. We run the same scenes again and compare metrics with the baseline: we check whether the bottleneck is gone and whether a new one has appeared — for example, increased loading time due to file splitting.
- Stabilization and regression. We fix reference measurements and add automated validation of the packing scheme so that the next batch of graphics does not break the achieved result.
- Project handover to the team. We hand over the splitting scheme, repacking scripts, regulations for adding new resources, and a short guide for artists — after that, the client’s team handles packing themselves, without us.
Each stage ends with an artifact: measurement, scheme, updated atlases, device report, regulations. This makes the result reproducible rather than dependent on one engineer.
Artifacts: Splitting Schemes, Memory Profiles, Regulations
After the work, the client’s team is left not with a report, but with a working kit: with it, a new engineer reproduces atlas assembly and gets the same result without contacting us.
Each document is tied to a specific step of the resource pipeline, so the discrepancy between “as agreed” and “as built” is visible immediately — at the verification stage, not on the player’s device.
- Resource splitting scheme — which groups of images are combined into one atlas, by what criterion (simultaneous display frequency, shared material, screen), and which remain separate files. With the sheet size limit and rules for filling free space.
- Application memory profile — consumption measurements on target devices before and after changes, broken down by scenes: loading, combat, UI, long session. Serves as a reference for comparison in future releases.
- Resource naming rules — a unified template for images, atlases, and derived files, so the builder automatically finds dependencies and searching for the needed sheet does not turn into directory scanning.
- Graphics revision regulations — who and when reviews atlas composition, what counts as a reason for repacking (new content set, increased consumption, complaints about loading), and how the result is recorded.
- Resource build documentation — the order of steps, tool composition, and control points with checks: unfilled areas, duplicates, resources outside the scheme. A new person can go from source files to a ready set without oral explanations.
- Ownership map — which files and settings are assigned to specific roles, what changes only through revision, and what can be edited locally.
We hand over the kit in a form suitable for editing: schemes and rules sit next to the project and are versioned with it, not in chat. After a few releases, the team returns to the documents, not to us — this is the criterion that the work is done.
Case: Eliminated Drops on Low-End Devices
What It Was Like Before the Work
A project came to us where graphics grew faster than they could be put in order: each new screen pulled its own set of textures, some images were duplicated across several atlases at once, and rare assets sat in a common pool and were always loaded.
On the lower bound of supported devices this produced drops in combat and during transitions between scenes — memory hit the ceiling, and loading happened exactly at the moment of player action.
What We Changed
We rebuilt atlases by actual co-occurrence: resources from one screen went into one set, rare ones were moved out separately with on-demand loading.
Duplicates were replaced with references to a shared source, the number of frames in animations was limited, and compression formats were selected for what the device decodes in hardware.
- removed atlas intersections between screens;
- moved reusable elements into a shared pool instead of copies;
- switched rare scenes to asynchronous loading with preloading during pauses;
- warmed the cache at startup so the first entry into combat did not assemble resources.
How We Measured the Result
We counted by fact, not by eye: the Unity project provides a per-frame profile, and we relied on it. We tested not on high-end models, but on the lower bound of the support list — the devices that actually bring installs.
The same set of scenes before and after: build size decreased by about a third, level loading became twice as fast, drops on low-end devices disappeared, and memory stopped hitting the ceiling.
What to Do If the App Is Already Released and Being Updated?
A released app updates at its own rhythm, and no one will stop releases to repack graphics. Texture atlas optimization is integrated into the current cycle: one wave — one screen or location. Each step must be rollback-able, otherwise the risk during an update outweighs the gain.
The key condition is resource backward compatibility. Old builds on devices continue to read previous sheets, while new ones read already repacked sheets: slot names and frame access keys are preserved, only the layout changes.
The previous set remains in the distribution until the share of players on outdated versions falls to negligible.
A smooth transition is built on measurements, not on belief in the gain. At each wave we compare occupied video memory, level loading time, and loading frequency during gameplay.
If the effect is not confirmed on the device matrix, the wave does not go into release — the changes wait in a branch.
The risks are known and closed in advance: artifacts at sheet edges during filtering and transition between detail levels, lost references after deleting old frames, build size growth during the transition period. We return to the previous scheme via a configuration flag, without an emergency update.
This way optimization proceeds in parallel with version releases, not instead of them: each wave gives a measurable slice of memory and loading, while the agreed look and behavior of the game for the player remain unchanged.
Filtering, Transparency, Memory: Common Questions
Such questions usually come up already on a call, when the draft atlas is assembled and it is visible where it drops. Below are short answers to what most often raises doubts for the client’s team.
The general principle is one: the atlas decision is made based on measurements — occupied memory, scene preparation time, number of texture switches per frame. Without these numbers, an argument about fringing or compression quality remains a matter of taste.
A fringe appears at the edges of elements — can this be fixed?
Yes, this is the most common artifact, and the cause is technical: filtering captures pixels from the neighboring element.
It is closed with a 2–4 pixel padding at the edge, where the outermost pixels are duplicated, and correctly assembled downscaled copies of the sheet — otherwise the fringe will appear on distant detail levels.
Can semi-transparent elements be kept in a shared atlas?
Yes, but with caveats: blending order and the way transparency is stored are critical.
If a semi-transparent element sits in one sheet with opaque ones, it blends with foreign pixels and produces a dark halo — we move such elements into a separate sheet or a separate rendering layer.
Why did memory grow after splitting the atlas?
Because each sheet is a separate texture with its own minimum size, edge padding, and its own downscaled copies. We split not “by folders,” but by compression format and element usage frequency: rare elements go into a separate sheet that loads on demand.
How can we make sure compression did not kill quality?
We compare the compressed sheet with a lossless reference, look at deviation by channels, and visually check gradients, thin lines, and small text. Elements sensitive to detail loss are kept on a separate sheet with a gentler mode.
Where should we start if the app simply “lags”?
With measurement. We capture the volume of loaded textures, their count, and scene preparation time, then see what changes during transitions between screens. Most often the bottleneck is not geometry, but texture volume and extra material switches per frame.
Let’s Discuss the Task: Scene Measurement, Work Plan, Estimate
Texture atlas optimization starts not with edits, but with scene measurement: without numbers, any change turns into guessing. To come back with a timeline estimate and a working plan, rather than general recommendations, we need the project’s starting data.
- current game build or repository access — a snapshot of the real state, not a retelling;
- list of scenes where drops are visible: level loading, combat, store screen, inventory;
- memory and rendering time statistics, if the team already collects them;
- list of atlases with sizes and packing rules: which sprite sets belong to which screen;
- constraints on target devices and the minimum supported system version;
- crash analytics and review data — where users more often complain about stuttering and device heating.
Based on this data, we assemble a work plan for optimization: atlas order, what we repack, what we split by screen, what we unload from memory between scenes. We attach a stage-by-stage timeline estimate to the plan — so you can see at which step a measurable result appears.
The order for starting work: discuss the task, agree on the scope of the first stage and control points, then fix the plan and start. Describe the task and send what already exists — we will come back with a work plan and estimate.