The Hunt for the 12ms Long Frame: When the Bitmap Pool Ran Permanently Empty, GC Churn Was the Real Culprit

“It stutters” is a feeling, and feelings are the least reliable informants. What actually convicted was that unremarkable pool=0.0/25MB in the log.

I. Falsify First: The Engine Never Collapsed

On-device, official release build, 60Hz panel — the first thing the data did was overturn our own hypothesis:

Scenario	fps mean	fps min	drawMax	>8ms frames	Peak on-screen	Cache hits
Live · medium-low density 90s	59.3	58.0	12.0ms	5 frames	17	100%
Live · denser 180s	58.2	54.0	12.2ms	18 frames	35	100%

The box’s FOS panel showed 240 FPS, which briefly suggested maxed out — but that was a decorative counter; the panel is actually 60Hz. That is, 59.3fps on a 60Hz panel means the danmaku engine almost maxed out its frame rate, and at this live-room density there was no engine performance problem. The in-house renderer plus text-prerendered bitmap plus smooth clock plus adaptive density architecture was healthy.

But the 10MB concurrent GC every 30 seconds in the log was worth watching. And pool=0.0/25MB — the bitmap pool never engaged — was a harder lead. The real culprit was not the engine but memory.

II. Root Cause Layer One: Pool and Budget Fighting Over One Allowance

Reading through CacheManager and BitmapMemoryBudget, the root cause was located quickly, and it was a design problem:

the pool and the bitmap budget shared the same 25MB allowance, and during budget reclamation evictPooled was first in line. This meant a danmaku bitmap had barely entered the pool when the next new danmaku requested allowance and emptied it for recycling — the pool never accumulated (pool=0), and all bitmaps cycled through create/recycle. That was the 10MB/30s GC churn, and the prime suspect for the 12ms long frames.

The fix was direct: change the reclamation order to evict the shared table first and keep the pool as the last resort.

The P1 scope was also corrected — one of the other two items was disproved by data. Immediate downshift stayed, but honestly: the measured minimum of 54fps (0.90 × 60Hz) never broke below the downshift line of 0.72, so this targeted the on-demand high-density scenario, not today’s live scenario. And the shadow switch was cut: the code’s danmaku bitmaps never went through setShadowLayer (stroke only), so this change had no measurement support and was not done.

III. Root Cause Layer Two: All Feeding Paths Blocked

The first fix went in and was retested. fps and long frames both improved — drawMax from 12ms to 2.5-4.3ms, over8=0 — but pool was still 0. The pool still had not eaten.

Digging deeper, the truth was one layer below: shared-table eviction (removeEldestEntry) and budget reclamation (evictShared) both called recycleBitmap directly, never passing through the pool. And the pool’s only feeding path (item release) was blocked by the shared table’s reference counting — the table never dropped its reference, so item release could never reach 0.

So the permanently empty pool was a design necessity, not a tuning problem. The fix: let shared-table eviction also go through recycleEntryBitmap, into the pool first and recycling only on failure.

IV. One Logical Self-Negation

After the third fix went in, the author stopped and found a hole:

the purpose of budget reclamation is to release memory, while bitmaps entering the pool still occupy allowance. With pool and budget sharing one allowance, the reclamation loop could never free space.

So the third fix was withdrawn and replaced with a coherent strategy: shared-table eviction under budget pressure recycles directly (releasing allowance), while conventional LRU overflow eviction enters the pool (stable feeding). Two kinds of eviction take two paths, each doing its own job.

This kind of mid-course withdrawal of one’s own fix matters more than piling on three patches at once — the former is design thinking, the latter is just code growing.

V. The Sampling Trap: pool=0 Was Normal in One Room

Third retest: pool still 0. But this time the question was asked first — this room itself was very sparse, 3-6 on screen with only 100 bitmaps. Checking MAX_SHARED_CACHE settled it: 100 bitmaps is below the shared table’s capacity of 256, so eviction never triggered, and pool=0 here was normal and could not validate the fix.

Change rooms. In the follow page, “全球总决赛” at 349k heat was the densest; sample for 3 minutes. The key data arrived: pool=1.5/25MB — the pool worked normally in the dense-stream room (328 bitmaps = 256 table + 72 pool, the feeding path effective).

And GC churn persisted (10MB roughly every 13 seconds) — indicating another allocation source: live danmaku message objects, not bitmaps. Both P1 fixes verified effective; the remaining allocation source is the next case.

VI. One Navigation Correction

Finding the dense room was not smooth either. Several navigations went astray — focus overshooting to the nav top, straying into the player, opening the wrong tab — until the owner simply specified: “My - History - first live room, that is it, stop searching yourself.”

That correction is worth recording: when the target is clear, exhaustive exploration loses to simply asking. The earlier blind collisions consumed not just time but the owner’s trust in the process.

VII. Wrap-Up: Restoration Matters as Much as the Fix

Measurement done, the data overturned the “the engine has a major problem” hypothesis and pinned down what was actually worth fixing. And both box and code were restored — the clean build was reinstalled, the log switch turned off, the probe patch removed and byte-identical to the pre-measurement state. Local was three commits ahead of Mac/GitHub (two measurement patches plus one revert, net effect zero), with nothing pushed to any remote.

This is the discipline of performance detection: what you leave behind must be a reproducible scene, not a pile of patches you cannot explain. The hunt for the twelve-millisecond long frame ended up treating not the engine but a pool that had been robbed of its allowance — and the entry point to discovering it was nothing more than that pool=0.0 most people skip past.