Mipmaps on a UI sprite are ~33% memory you never sample

A full mip chain adds about 33% to a texture’s memory — the sum of all the smaller levels is a third of the base level. That’s a good trade for a 3D surface you view at varying distances. For a UI sprite drawn 1:1 on a canvas, the smaller levels are never sampled, and you’re paying a third extra for nothing.

What the scan looks at

Textures whose importer Texture Type is Sprite (2D and UI) or Editor GUI and Legacy GUI, with Generate Mip Maps enabled. Type-based, so it doesn’t guess from folder names: if you’ve told Unity the asset is a sprite, the mip chain is dead weight by construction.

Why it costs you

Mip selection is driven by how the texture is minified on screen. Canvas UI at native scale hits mip 0 and stays there. The rest of the chain is uploaded, resident, and shipped anyway — memory, VRAM, and build size, for pixels the sampler never reads.

Sprites imported with a preset built for 3D art are the usual source. It’s also the kind of setting nobody revisits, because nothing visibly breaks.

How to fix it by hand

Select the sprite, untick Generate Mip Maps in the Inspector, reimport. Do it on the whole folder at once — multi-select works, and sprite atlases inherit the setting from their members.

The one case to check first: sprites used in a world-space canvas, or on quads in 3D space, can be minified and will alias without mips. If your UI is screen-space overlay (the default), that doesn’t apply.

What PerfLint does about it

The scan lists every sprite that has mips on, with the memory the chain is costing. Pro can turn the flag off from the finding row, one sprite or the whole group in one action — it’s an importer setting, so it’s reversible and Unity reimports for you.

Severity is Info rather than Warning because the per-asset amount is usually small; it earns its place by being safe and bulk-applicable, which makes the group total worth more than any single finding on the list.