[ymote]

Why

A performance soak of the phone's All apps list on a OnePlus 6 (Android 15, 60 Hz) found that scrolling feels slow because of lag, not frame rate. The soak ran main 8b98596 as a test package for 60 minutes: 960 scripted drags, flings and flicks with 8 ms touch injection, measured against SurfaceFlinger present times and phone.frames.

• Frame rate: a median of 60 fps, with flat memory and no crashes.

• Lag: within a drag, the delay from finger to screen is constant, but it falls into one of three groups:

  Finger-to-screen delay	Share of drags
  ~37 ms	53%
  ~53 ms (one extra frame)	40%
  ~70 ms (two extra frames)	8%

  The first drag after opening All apps is always in the slow groups.

• Cause: buffer stuffing in Makepad's Android frame loop. A frame takes about 12 ms from the vsync beat to the queue, against a latch at about 16 ms. One slow frame, usually the first after idle, misses the latch, and every later frame waits one refresh in the queue until the app goes idle. Instrumented runs found 55 such events and no recoveries.

What

This stacks OctoSense-org/makepad#128 on the pinned Makepad (d653bc44) as tools/runtime-patches/makepad-android-buffer-stuffing.patch, and updates runtime-patches.lock.json with the stacked entry, its sha256, the tree and a product_fixes line.

• On API 33+, the Choreographer beat carries the frame's expected presentation time from VsyncCallback FrameData.
• EGL frame timestamps report each frame's display time.
• When two frames in a row reach the screen at least half a refresh after their expected time while a finger is down, one beat is left unpainted so the extra queued frame drains.
• setprop debug.makepad.stuffing off disables it.

The next Makepad sweep drops this patch once #128 is merged upstream into our fork's main.

Device results

OnePlus 6, a Home test package built from this branch (dev.makepad.octosense.scrollfinal, 0833dfe). Production Home was not replaced. All apps, recovery off or on through the property, two interleaved rounds of 5 minutes each:

	Off	On
Drags at ~37 / ~53 / ~70 ms	38% / 46% / 16%	82% / 18% / 0%
Median drag delay	53.4 ms	37.0 ms
Dropped frames per gesture	0.89	1.10
Skips	—	56

The extra dropped frames are the stuffed queue's lost cushion. A slow frame now shows as one repeated frame, mostly at the start of a drag and in its coast; fling coasts are unchanged. The follow-up that removes both is cheaper frames: GL encode is 5 ms of the 12.

The table above is from 0833dfe. 152001a then armed the detector only while a finger is down. 4c04edf stacks #128's second commit. A refresh without a new frame drains the queue, so frames painted before one never arm a skip. Re-checked with a test package built from 4c04edf (dev.makepad.octosense.scrollfinal2):

• Touching again right after a fling (the finger lands about 0.2 s after the fling stops). 0833dfe and 4c04edf ran interleaved, 2 × 4 minutes each. Skips armed by the fling's own frames fell from 10 of 76 touches to 0 of 81. Missed refreshes in the first 300 ms after the touch fell from 0.18 per touch to 0.
• Same session, off and on. Drags with an extra queued frame went from 3 of 46 to 0 of 45, and dropped frames per gesture from 0.59 to 0.56. The phone stuffed far less often than in the run above.
• Input timing. In every run, on or off, 8 to 13 of 45 drags lag a frame before the draw: the touch reaches the draw a frame late. That is input timing, which this patch doesn't touch.

Checks

• Local CI (tools/ci-local.sh --linux-host --offload) passed on 4c04edf in 17m43s. GitHub's embedded-browser (Windows) check passed on the same head.
• python3 tools/setup.py --check --cargo passes.
• The patch replays cleanly onto the locked tree.
• Makepad side, from ADR 0004 follow-ups: contacts for approval rules; refresh ai-services docs [skip ci] #128: Android and macOS cargo check is clean for this change, and makepad-platform lib tests pass (253).
• Not run: Android below 33 (fallback path) and devices other than the OnePlus 6. Backport Makepad native optimizations and reduce Android drawer latency #475's own Android presentation patch has not been tested together with this one.

🤖 Generated with Claude Code